500 Miles

BLOG: Uhura Uraniae

Ko(s)mische Streifzüge durch Zeit und Raum
Uhura Uraniae

Dieser humoristische Beitrag liegt im Original beim MIT. Der “Ich”-Erzähler nennt sich Trey Harris. Vielleicht sollte man so seine Bewerbungen schreiben: 

Hier ist ein Problem, das *unmöglich* klang… Ich bereue fast, dass ich die
die Geschichte an ein breites Publikum schicke, weil sie eine großartige Geschichte bei Drinks auf einer Konferenz ist. 🙂 Die Geschichte ist leicht abgewandelt, um die Schuldigen zu schützen, irrelevante und langweilige Details auszulassen und generell die Sache unterhaltsamer zu machen.

Ich arbeitete vor einigen Jahren in einem Job, in dem ich das E-Mail-System des Campus verwaltete als ich einen Anruf vom Vorsitzenden der Statistikabteilung bekam.

“Wir haben ein Problem mit dem Versand von E-Mails aus der Abteilung.”

“Was ist das Problem?” fragte ich.

“Wir können keine E-Mails über mehr als 500 Meilen verschicken”, erklärte der Vorsitzende.

Ich verschluckte mich an meinem Milchkaffee. “Wie bitte?”

“Wir können keine Post weiter als 500 Meilen von hier verschicken”, wiederholte er. “Ein bisschen mehr, eigentlich. Nennen wir es 520 Meilen. Aber nicht weiter.”

“Ähm … E-Mail funktioniert normalerweise nicht auf diese Weise”, sagte ich und versuchte die Panik aus meiner Stimme herauszuhalten. Man zeigt keine Panik, wenn man mit einem wenn man mit einem Abteilungsleiter spricht, selbst in einer relativ armen Abteilung wie Statistik. “Wie kommen Sie darauf, dass Sie die Post nicht weiter als 500 Meilen?”

“Es geht nicht darum, was ich *denke*”, antwortete der Vorsitzende gereizt. “Sehen Sie, als wir das zum ersten Mal bemerkten, vor ein paar Tagen–“

“Sie haben ein paar TAGE gewartet?” Ich unterbrach ihn, ein Zittern in der Stimme. “Und Sie konnten die ganze Zeit keine E-Mails verschicken?”

“Wir konnten E-Mails verschicken. Nur nicht mehr als -“

“–500 Meilen, ja”, beendete ich für ihn, “das habe ich verstanden. Aber warum haben Sie nicht früher angerufen?”

“Nun, wir hatten nicht genug Daten gesammelt, um sicher zu sein, was vor sich geht. bis gerade eben.” Aha. Das ist der Vorsitzende der *Statistik*. “Wie auch immer, habe ich einen der Geostatistiker gebeten, sich das anzusehen…”

“Geostatistiker…”

“-Ja, und sie hat eine Karte erstellt, die zeigt, dass der Radius, in dem wir
in dem wir E-Mails senden können, etwas mehr als 500 Meilen beträgt. Es gibt auch eine Reihe von Zielen innerhalb dieses Radius, die wir nicht oder nur sporadisch erreichen können. Aber wir können niemals weiter als diesen Radius mailen.”

“Ich verstehe”, sagte ich und stützte den Kopf in die Hände. “Wann hat das angefangen? Vor ein paar Tagen, sagten Sie, aber hat sich zu diesem Zeitpunkt irgendetwas an Ihren Systemen geändert?”

“Nun, der Berater kam und hat unseren Server gepatcht und neu gebootet.
Aber ich habe ihn angerufen und er sagte, dass er das Mailsystem nicht angefasst hat.”

“Okay, lassen Sie mich einen Blick darauf werfen, und ich rufe Sie zurück”, sagte ich und konnte kaum glauben, dass ich mitspielte. Es war kein Aprilscherz. Ich versuchte mich zu erinnern, ob mir jemand einen Scherz schuldete.

Ich loggte mich in den Server von deren Abteilung ein und schickte ein paar Testmails. Dies war im Forschungsdreieck von North Carolina. Auch eine Testmail an mein eigenes Konto wurde ohne Probleme zugestellt. Dasselbe gilt für die Mails nach Richmond, Atlanta und Washington. Eine weitere nach Princeton (400 Meilen) funktionierte.

Aber dann habe ich versucht, eine E-Mail nach Memphis (600 Meilen) zu senden. Es schlug fehl. Boston, gescheitert. Detroit, gescheitert. Ich holte mein Adressbuch heraus und begann zu versuchen, die Sache einzugrenzen. New York (420 Meilen) hat funktioniert, aber Providence
(580 Meilen) schlug fehl.

Ich begann mich zu fragen, ob ich meinen Verstand verloren hatte. Ich versuchte eine E-Mail an einen Freund zu mailen, der in North Carolina lebte, aber dessen ISP in Seattle war. Zum Glück schlug es fehl. Wenn das Problem mit der Geographie des menschlichen Empfängers zu tun gehabt hätte und nicht mit seinem Mailserver zu tun gehabt hätte, wäre ich wohl am Boden zerstört in Tränen ausgebrochen.

Nachdem ich festgestellt hatte, dass das gemeldete Problem -unglaublicherweise – wahr und reproduzierbar war, warf ich einen Blick auf die Datei sendmail.cf. Die Datei sah ziemlich normal aus. Tatsächlich sah sie vertraut aus.

Ich verglich sie mit der sendmail.cf in meinem Home-Verzeichnis. Sie war nicht verändert worden geändert worden – es war eine sendmail.cf, die ich geschrieben hatte. Und ich war mir ziemlich sicher, dass ich die Option “FAIL_MAIL_OVER_500_MILES” nicht aktiviert hatte. Ich war ratlos und
telnettete ich den SMTP-Port an. Der Server antwortete fröhlich mit einem SunOS sendmail-Banner.

Moment mal… ein SunOS-Sendmail-Banner? Zu dieser Zeit lieferte Sun immer noch Sendmail 5 mit seinem Betriebssystem aus, obwohl Sendmail 8 schon ziemlich ausgereift war. Da ich ein guter Systemadministrator war, hatte ich mein System auf Sendmail 8 standardisiert. Und auch weil ich ein guter Systemadministrator war, hatte ich eine sendmail.cf geschrieben, die die schönen langen selbstdokumentierenden Options- und Variablennamen
Options- und Variablennamen verwendet, die in Sendmail 8 zur Verfügung stehen, anstatt die kryptischen Satzzeichen Codes, die in Sendmail 5 verwendet wurden.

Die Teile fügten sich auf einmal zusammen, und ich verschluckte mich wieder am Bodensatz meines nun kalten Milchkaffees. Als der Berater den Server “gepatcht” hatte, hatte er offenbar die Version von SunOS aktualisiert und dabei Sendmail *downgraded*. Das Upgrade ließ hilfreicherweise die sendmail.cf  in Ruhe, obwohl sie nun die falsche Version war.

Zufälligerweise konnte Sendmail 5 – zumindest die Version, die Sun mit einigen Optimierungen ausgeliefert hatte – mit der sendmail.cf von Sendmail 8 umgehen konnte, da die meisten die meisten der Regeln zu diesem Zeitpunkt unverändert geblieben waren. Aber die neuen
langen Konfigurationsoptionen – die sah es als Müll an und übersprang sie.

Die sendmail-Binärdatei hatte für die meisten dieser Optionen keine Standardwerte einkompiliert, so dass keine passenden Einstellungen in der Datei sendmail.cf gefunden wurden. Diese wurden auf Null gesetzt.

Eine der Einstellungen, die auf Null gesetzt wurde, war der Timeout für die Verbindung zum entfernten SMTP-Server. Einige Experimente ergaben, dass auf  bestimmten Rechnern mit seiner typischen Last, ein Timeout von Null einen Verbindungsaufruf nach etwas mehr als drei Millisekunden abbrechen würde.

Ein merkwürdiges Merkmal unseres Campus-Netzwerks zu dieser Zeit war, dass es zu 100% geswitcht war. Ein ausgehendes Paket würde keine Router-Verzögerung erfahren, bis es auf den POP trifft und einen Router auf der anderen Seite erreicht. Die Zeit für die Verbindung zu einem leicht belasteten entfernten Host in einem nahe gelegenen Netzwerk zu verbinden, würde tatsächlich weitgehend von der Lichtlaufzeit zum Zielort und nicht von zufälligen Router-Verzögerungen bestimmt.

Mit einem leichten Schwindelgefühl tippte ich in meine Shell:

$ units
1311 Einheiten, 63 Präfixe

Sie haben: 3 Millilichtsekunden
Sie wollen: miles
* 558.84719
/ 0.0017893979

“500 Meilen, oder ein bisschen mehr.”

 

Veröffentlicht von

"physics was my first love and it will be my last physics of the future and physics of the past" Die Autorin ist seit 1998 als Astronomin tätig (Universitäten, Planetarien, öffentliche Sternwarten, u.a.). Ihr fachlicher Hintergrund besteht in Physik, Wissenschaftsgeschichte und Fachdidaktik (neue Medien). Sie ist aufgewachsen im wiedervereinigten Berlin, zuhause auf dem Planeten Erde.

5 Kommentare

  1. Eine der Einstellungen, die auf Null gesetzt wurde, war der Timeout für die Verbindung zum entfernten SMTP-Server.
    […]
    Die Zeit für die Verbindung zu einem leicht belasteten entfernten Host in einem nahe gelegenen Netzwerk zu verbinden, würde tatsächlich weitgehend von der Lichtlaufzeit zum Zielort und nicht von zufälligen Router-Verzögerungen bestimmt.

    Es gibt halt physikalisch erklärbare Verzögerung beim hier gemeinten Datenaustausch und die sogenannte Latency :

    -> https://en.wikipedia.org/wiki/Latency_(engineering)

    Die Latenz ist ergo versteckt und meint Systemreaktion, die den Kommunkationsfluss hemmen kann, es gibt hier auch das Kürzel ‘LAG’.

    Mit derartigen Problemen, also wenn konfigurierte Werte “auf einmal” überschrieben werden, gar auf Standardwerte wie NULL, ‘O’ oder ” (leerer String), machen den Administrator sozusagen happy.
    Dann lebt er sozusagen auf (sofern er es nicht selbst irgendwie verbockt hat, frei von Schuld ist und sozusagen alleinig die Problemlösung gefunden hat).
    Er kennt derartige Problematik nicht selten und berichtet gerne davon.

    Mit freundlichen Grüßen
    Dr. Webbaer

  2. Die Realität war durchaus schwerer zu ertragen als der Beitrag von Trey Harris vermuten lässt. Irgendwann wurde ein jeder Arbeitsplatz mit Workstations von HP und HP-UX 10.0 ausgestattet. Das System war gut durchdacht und leidlich stabil, wenn man von kleineren Macken absah:

    In einer Übergangsphase waren auch noch Apollo/Domain Workstations im Einsatz. Verschob jemand ein auf einer HP liegendes Dokument mit einer Apollo über das Netzwerk in den Papierkorb landete die HP selbst im Nirwana; an sich kein Problem, da man sie ja wieder booten konnte.

    sendmail war sehr tüchtig. Die Administratoren hatten aber keine Ahnung. Aus heiterem Himmel (jemand hatte ein falsche Mailadresse verwendet) beschäftigte sich das Netzwerk fast ausschließlich mit unzustellbarer Mail. Abschalten und von vorne anfangen war auch hier die Lösung der Administration.

    Die Liste ließe sich beliebig fortsetzen. Erst zwanzig Jahre später wurde alles gut. Was ich mir damals so dringend gewünscht hatte ist heute selbstverständlich. Linus Torvalds und sehr viele andere machten es möglich.

    • Und wer nächtens ganz aufmerksam war, konnte Arbeitsstationen und Servern beim Wiederhochfahren lauschen, in der Wildnis sozusagen.

  3. Ich kontrolliere die Ergebnisse der Software-Übersetzung (Deepl etwa) auch nicht (immer vollständig), und dann kommenTextübersetzungen raus, wie hier zu lesen.

    Ein scheinbar typisches Verhalten von Deepl-Übersetzung – manchmal.

Schreibe einen Kommentar