Me encantan las anécdotas, y más cuando son de informática.

En unos DOC’s perdidos dentro de un directorio TEMP que estaban dentro de un directorio TEMP, encontré una hermosa historia (real) de una persona encargada del servidor de correos de una empresa que de una manera inverosímil, no enviaba correos a más de 500 millas y obviamente, la primera reacción del sysadmin y la segunda cuando se da cuenta de la existencia de tan «bizarro» problema.

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. (continúa…)

“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

23 COMENTARIOS

  1. Los correos que no llegaban a mas de 500 millas

    […] Los correos que no llegaban a mas de 500 millas tecnovortex.com/el-caso-de-los-correos-que-no-llegaban-a-mas-…  por guachindango hace 3 segundos […]

  2. nacho

    lo que es admirable es la precisión del depto de estadística para expresar el problema!

    • eVeR

      claaaaaaaro! ¿Por que no le tocó la clásica explicación «no anda el mail»? ¿O la aún mas clásica «la compu de vilvió loca»? Ahí sería un usuario mas creíble! jaja.

      Muy buena la anecdota, yo no la conocía

  3. siempre hay un boludo que comenta «eso es más viejo que…» y no quiero ser yo ese boludo, pero te cuento que esta anécdota informática es muy conocida, tanto que yo diría que es LA anécdota informática.
    Y sí, es genialmente inesperada.

    • Si, pero bueno, yo no la conocía.

      Y parece que muchos tampoco

      Que se yo, es como alguien que dice «el publico se renueva»

      • Javier Eduardo Sola

        Yo si la conocia…..pero ya me la habia olvidado…. Gracias por el recuerdo.

        Ahora el calculo no se podría aplicar, con todo el porno que satura las redes….. imposible el timeout de 3ms para 550 millas.

        Abrazo.

    • Nico

      Yo tampoco, gracias por compartirla!

  4. Juan

    Como dice maju lozano a la mañana en la100, está chequeado esto?

    A mi no me vengan con pasar de esto a aquello, yo soy de la vieja escuela, bueno en fin, aca les dejo el procedimiento a mano ya que lo hice…

    3 milisegundo = 0,003 segundos

    299.792,5 km/s = velocidad de la luz, a metros (para trabajar en MKS) = 299 792 000 m/s
    299 792 000*0,003=899 376 metros
    899,376 kilómetros = 558,846337 millas

    558,846337 millas

    Muy muy buena, yo tampoco la conocia..

  5. Nadius

    ¡Genial, no la conocía! Ya quisiera ver cómo reaccionarían mis compañeros de la facultad en una situación como esta, teniendo en cuenta cómo se lamentaron cuando el sysadmin les bloqueó Facebook XDDD

  6. sip, definitivamente no la conocia, y me volveria loco arreglar un bug asi, mas aun, siquiera diagnosticar el problema en cuestion

    • Javier Eduardo Sola

      La anécdota es genial, pero viendo el log, debería aparecer el timeout de la conexión…. o estoy crazy macaya?!

  7. Guido

    Genial!

    A proposito… tenia entendido que en el cable los datos no viajan a la velocidad de la luz

  8. Rodrigo Sarria

    Buena anécdota en serio, un admin «joven» en la actualidad no resolvería el problema sin volverse medio chango y canoso en el intento, dicho sea de paso allá por el 2004/2005 cuando trabajaba como BOFH en un ISP tuvimos el caso de una señora de edad que se quejaba de que ahora que se mudó mas lejos (del microcentro a unos 10Km max) «la señal le llegaba menos y era lento el internet», revisé su plan contratado y era de 1Mb por ADSL, de tanta insistencia fui a revisar el asunto a su domicilio y los valores de SNR (señal en relacion a ruido) estaban normales, medí la velocidad con DU Meter bajando algo de un FTP que teniamos y normal, llegaba a su 1MB sin dramas pero ella seguía quejándose 2 o 3 veces por semana, bueno, pensando un poco se me dio por revisar el iptable donde estaban las limitaciones de velocidad y demás (trabajabamos asi por capricho de un Elder de la oficina que siempre estuvo ahi) y CHAN! en su anterior domicilio no tenia limitación de velocidad! cosa que se corrigió cuando le mudaron de server y agregaron su nombre, Ip y limitación según el plan contratado!

    La vieja se chupaba todo el ancho de banda por las noches! por eso habian cientos de quejas de la zona por las noches! y ahora que tenía la velocidad «normal» de su plan por supuesto que le era «lento» y no, no era problema de que se mudó muy lejos y tenía «menos señal» cosa que los monos de Soporte de Campo no pudieron solucionar ni explicar nunca! jajaja

  9. Diego M. - PepiMDQ

    Muy buenas las anécdotas de la nota y la de Rodrigo Sarria.

    Da gusto leer estas cosas que le sacan canas verdes y como lo resuelven.

  10. gonzalo

    los administradores de sistema de esa época tenían que saber o saber! muy buena historia!!!

  11. Scorch

    Esto me hace acordar a esos cuentos cortos de Isaac Asimov como «La máquina que ganó la guerra», incluso la prosa es bastante similar.

    Linda anécdota!

Dejá una respuesta

Por favor ingrese su comentario!
Por favor ingrese su nombre aquí