La historia que se relata a continuación no es propia, todos los derechos son reconocidos a su autor Trey Harris y la pueden encontrar en su idioma original en idioma Inglés en el siguiente link.
Hace más de un par de lunas un muy buen compañero de trabajo compartió esta historia que siempre encontré divertida e ilustrativa, digna de ser traducida al español y compartida cuantas veces sea posible. A continuación se presenta la historia del correo electrónico de las 500 millas, apareció originalmente en una publicación para “sage-members” el Domingo 24 de Noviembre del 2002:
Aquí hay un problema que sonaba imposible…. Casi lamento publicar la historia, sin embargo, es algo que vale la pena contar entre bebidas en cualquier conferencia. La historia se modifica ligeramente para proteger al culpable, se evitan detalles irrelevantes y aburridos, esto con el fin de hacer todo más entretenido.
Hace algunos años, estaba trabajando en tareas para ejecutar el sistema de correos del campos, cuando recibí una llamada del presidente del departamento de estadística.
De Trey Harris Vie 29 de noviembre 18:00:49 2002 Para: sage-members@sage.org Subject: El caso del correo electrónico de las 500 millas (originalmente RE:SAGE Tarea imposible favorita?)
“Estamos teniendo problemas para enviar correos electrónicos fuera del departamento”.
“¿Cuál es el problema?” Yo pregunté.
“No podemos enviar correo a más de 500 millas”, explicó el presidente.
Me atraganté con mi café. “¿Puedes repetirlo?”
“No podemos enviar emails a más de 500 millas”, repitió. “Tal vez un poco más, en realidad una 520 millas, pero no más”.
“Um … En general, el correo electrónico no funciona de esa manera”, dije, tratando de guardar la calma y evitando la más ligera muestra de pánico en mi voz. Uno no muestra pánico cuando habla con un jefe de departamento. “¿Qué te hace pensar que no puedes enviar a más de 500 millas?”
“No es lo que pienso”, respondió el presidente un tanto irritado. “Notamos este comportamiento por primera vez hace unos días…”
“¿Esperaste unos días!?” Interrumpí, escuchaba un pequeño temblor en mi voz. “Y ¿No pudiste enviar correos electrónicos todo este tiempo?”
“Podíamos enviar correos electrónicos. Solo que a no más de …”
“- 500 millas, sí”, terminé por él, “Me quedo claro. Pero ¿Por qué no llamar antes?”
“Bueno, no habíamos recopilado suficientes datos para estar seguros de lo que estaba pasando hasta ahora.” Correcto. Este es el presidente de estadísticas.”De cualquier manera, le pedí a uno de los geoestadísticos que lo investigara … “
“Geoestadísticos …”
“… Sí, y ha elaborado un mapa que muestra el radio dentro del cual podemos enviar correos electrónicos, el cual parece ser un poco más de 500 millas. Hay una serie de destinos dentro de ese radio que no podemos alcanzar, por lo menos no de forma definitiva, estos destinos son intermitentes, pero no podemos enviar correos electrónicos más allá de este radio”.
“Ya veo”, dije, y puse mi cabeza en mis manos. “¿Cuándo empezó esto? Mencionó que hace unos días, pero ¿Cambió algo en sus sistemas en este tiempo?”
“Bueno, vino el consultor e instaló la última actualización en nuestro servidor y lo reinició. Pero lo llamé y me dijo que no toco el sistema de correo”.
“Está bien, déjame echar un vistazo, y te llamo”, dije, todavía pensando que podía estar jugando. No era el día de los inocentes e intenté recordar si le debía una broma pesada a alguien.
Me conecté al servidor de su departamento y envié algunos correos de prueba. Esto estaba en el Triángulo de Investigación de Carolina del Norte, envíe un correo de prueba a mi cuenta que se entregó sin problemas. Lo mismo ocurre con uno enviado a Richmond, Atlanta y Washington. Otro a Princeton (400 millas) funcionó.
Pero luego intenté enviar un correo electrónico a Memphis (600 millas), falló. Boston, falló. Detroit, falló. Saqué mi libreta de direcciones y comencé tratando de reducir esto; Nueva York (420 millas) funcionó, pero Providence (580 millas) falló.
Empezaba a preguntarme si había perdido la cordura. Intenté enviar un correo electrónico a un amigo que vivía en Carolina del Norte, pero cuyo ISP estaba en Seattle. Afortunadamente, falló. Si el problema hubiera tenido que ver con la geografía del destinatario humano y no su servidor de correo, creo que hubiera roto en lágrimas.
Habiendo establecido que, increíblemente, el problema según lo informado era cierto, verificable y repetible, eché un vistazo al archivo de configuración “sendmail.cf”. Se veía bastante normal. De hecho, me resultó familiar.
Lo comparé con el “sendmail.cf” en mi directorio personal. No ha sido alterado, era el “sendmail.cf” que yo había escrito y estaba bastante seguro de que no había habilitado la opción “FALLARAMASDE500_MILLAS”. Perdido, me conecté a través del comando telnet al puerto SMTP. El servidor respondió felizmente con el banner de correo electrónico de SunOS.
Un minuto … ¿Un banner de correo electrónico de SunOS? En ese momento, Sun todavía utilizaba Sendmail 5 con su Sistema Operativo, aún cuando Sendmail 8 ya era bastante robusto. Como buen administrador de sistemas, me había propuesto estandarizar todo utilizando Sendmail 8. Y también, como buen administrador del sistema, había escrito un archivo de configuración “sendmail.cf” que usaba la opción y variable de “self-documenting” disponible en Sendmail 8, esto en lugar de los código de puntuación críptico que se habían utilizado en Sendmail 5.
Las piezas cayeron en su lugar, todas a la vez, y nuevamente me atraganté con la escoria de mi café ahora frío. Cuando el consultor “actualizó el servidor”, aparentemente había actualizado la versión de SunOS, y al hacerlo se re-instalo la versión por default de Sendmail, que es Sendmail 5. La actualización amablemente no eliminó el archivo “sendmail.cf”, aunque ahora era incompatible con la versión actual.
Sucede que en Sendmail 5, al menos la versión que envió Sun, tenía algunos ajustes: Podía manejar el archivo de configuración “sendmail.cf” de Sendmail 8, ya que la mayoría de las reglas habían permanecido inalteradas en ese momento. Pero algunas nuevas opciones de configuración: las vio como basura y las omitió. Al mismo tiempo, el archivo binario de sendmail no tenía valores predeterminados compilados y para la mayoría de estos, la opción por defecto era cero, por lo que había ciertas configuraciones erróneas.
Una de las configuraciones que se estableció en cero fue el tiempo de espera (timeout to connect) para conectarse al servidor SMTP remoto. Algunos experimentos establecieron que en esta máquina en particular, con su carga típica, un tiempo de espera de cero abortaría una llamada de conexión que estuviera a poco más de tres milisegundos.
Una característica extraña en ese momento dentro de la red del campus es que estaba “100% switched”, lo que significa que un paquete saliente no incurriría en un retraso por parte del enrutador hasta que parta del protocolo POP y desde ese punto hasta llegar al enrutador en el lado opuesto. Así que el tiempo para conectarse a un servidor remoto con poca carga en una red cercana sería en gran medida regido por la distancia del destinatario más que por retrasos incidentales del enrutador.
Sintiéndome un poco mareado, escribí en la consola de comandos:
$ units
1311 units, 63 prefixes
You have: 3 millilightseconds
You want: miles
* 558.84719
/ 0.0017893979
“500 millas, o un poco más”.
Trey HarrisSi han llegado hasta aquí les agradezco la oportunidad para compartirles esta historia, la cual encuentro ingeniosa, entretenida y un ejemplo de cómo se va realizando el análisis para poder identificar la causa del problema en el mundo de los sistemas y en cualquier rama; ¿Quién no ha tenido ese sentimiento de sentirse completamente perdido hasta que no empieza a relacionar un comportamiento con otro y va encontrando el camino que debe recorrer hasta llegar a la causa del problema? Unas veces un poco más sencillo que en otras ocasiones.
¿Te ha pasado algo similar? ¡Compartelo! Envíame un mensaje, siempre es un gusto leer este tipo de historias.