Aus dem Rechenzentrum

Soeben bin ich in c’t 2009, Heft 21, über folgendes Zitat gestolpert, das in den aktuellen Debatten um Netzneutralität aktueller scheint denn je:

We reject: kings, presidents and voting.
We believe in: rough consensus and running code.

Es stammt von David D. Clark, Chief Protocol Architect des Internet, und schöner hätte man den Pragmatismus, der oft entsteht, wenn Entwickler unter sich sind, kaum in ein Fazit fassen können. Passend dazu lese ich heute: USA lockern Kontrolle über Internet-Verwaltung. Und gleichzeitig auf ZDnet.de via Holgi:

[…] Vodafone scheut nicht davor zurück, den IP-Verkehr mit einem anderen Knoten im Internet zu unterschlagen und dem Anwender eine eigene Antwort mit gefälschtem Absender zu senden. Dieser Eingriff in das Fernmeldegeheimnis ist durch kein Gesetz gedeckt. […] Während die Provider in den USA zur Netzneutralität verpflichtet werden, beginnen sie in Deutschland mit der wohlwollenden Duldung durch Regierung und Regulierungsbehörde damit, immer mehr Verkehr zu blockieren und zu fälschen.

Aus diesem Artikel konnte ich dann auch noch erfahren, dass Vodafone bereits seit Juli dieses Jahres allen Traffic über Port 53 tcp/udp zu den eigenen DNS-Servern umleitet, wobei mir noch nicht ganz klar ist, wie dann ein vom Artikel vorgeschlagener lokaler Resolver eine „Lösung“ darstellen soll, denn letztlich muss dieser ja mit den Root-Nameservern und den von jenen delegierten Nameservern ebenfalls auf Port 53 kommunizieren. Sinn ergibt dieses Aussage von daher eigentlich nur, wenn Vodafone nur Port-53-Traffic mit gesetztem Recursion-Flag an seine Resolver umleitet – ansonsten würde der lokale Resolver gar nichts bringen, da er seine Antworten dann ja auch nicht aus dem „echten“ Internet erhielte, sondern von den Vodafone-eigenen DNS-Servern. Vielleicht lässt sich das ja noch aufklären.

Aber so oder so: Ich bin schon reichlich bestürzt, mit was für „Problemen“ (eigentlich könnte man eher von „Unverschämtheiten“ sprechen) man sich inzwischen herumschlagen muss. Ich für meinen Teil hätte gerne das echte Internet und nicht das Kinder-Internet von Vodafone.

Eine obskure Firma namens Elda CBC Srl. mit Postanschrift in Rumänien treibt neues Unwesen mit bekannter Masche: Per Fax bekommen Firmen Adressbucheinträge zur Ergänzung vorgeschlagen – und wer diese ergänzt zurücksendet, bekommt die Rechnung von über 2.000 Euro präsentiert. So alt, so bekannt. Dennoch fallen immer noch Firmen darauf herein – schlimm genug.

Die fragliche Firma Elda hat nun bei einem meiner Kunden einen Webspace mit Domain geordert und dort den Zugriff auf das Branchenbuch ermöglicht, oder besser gesagt: Es zumindest versucht. Die Seite war nämlich völlig kaputt. Davon abgesehen gab es dort auch keine Eintragungsmöglichkeit – die Abzock-Falle beschränkte sich auf Faxe; im Web war nichts zu erkennen, was rechtlich zu beanstanden gewesen wäre.

Nun findet sich aber eine Website namens verbraucherabzocke.info im Netz, die es sich zum ehrenwerten Ziel gemacht hat, Informationen zu solchen Abzockern zu sammeln und zu veröffentlichen. Da sich die Macher der Seite offensichtlich wiederholt den Aggressionen der Abzocker ausgesetzt gesehen haben, wird diese per anonymem Offshore-Hosting betrieben, sprich: Inhaber der Domain ist nur ein Treuhänder; die Server stehen in irgendeinem Land, in dem es nach Eigenaussage des Hosting-Betreibers praktisch keine Rechtsverfolgung gibt.

Eben jene Macher von verbraucherabzocke.info betätigen sich nun offensichtlich als Detektive: Als seien diese Informationen irgendwie geheim, wird auf der Seite „aufgedeckt“, auf welcher IP-Adresse die böse Website betrieben wird, und man kommt darüber auf den Serverbetreiber (meinen Kunden), den Betreiber des Rechenzentrums und letzten Endes – auf meinen Namen. In fett und rot, und mit vollständiger Adresse. Unter dem Titel „Wer steckt dahinter?“. Nun ist natürlich die technische Verfolgung dieser Kette nicht falsch, auch wenn das auch jeder andere mit profundem Internetwissen hinbekommen hätte. Suggiert wird allerdings durch den Titel des betreffenden Abschnitts der Website und nicht zuletzt durch die besonders hervorgehobene Schreibweise meines Namens, man habe hier gewissermaßen den „Hintermann“ der Elda CBC Srl. aufdecken können (ganz so, als wenn ich mich zuvor irgendwie versteckt hätte). Das ist natürlich grundfalsch. Als technischer Betreiber kann ich ungefähr soviel für die Machenschaften der Elda CBC Srl. wie ein Mobilfunkbetreiber etwas dafür kann, dass sich ein Bankräuber per Handy mit seinem Komplizen verständigt – nämlich genau gar nichts.

Um kurz vorzugreifen: Selbstverständlich heiße ich die Aktivitäten jener Firma Elda keinesfalls für gut – im Gegenteil. Und ich unterstütze grundsätzlich auch jedes Anliegen des Verbraucherschutzes, solchen Firmen das Handwerk zu legen. Allerdings ist eine öffentliche Anprangerung unter Suggerierung falscher Tatsachen dann doch nochmal ein anderes Kaliber.

Nach Rücksprache mit meinem Kunden, bei dem jene Firma Domain und Webspace erworben hatte, entschied jener sich dazu, bis zur Klärung der Rechtslage die Domain vorübergehend zu deaktivieren. Ein mutiger Schritt, denn immerhin ist er seinem Kunden gegenüber vertraglich zur Leistungserbringung verpflichtet, und ich betone nochmal: Im Web hat die Firma meiner Ansicht nach keine Rechtsverletzung begangen. Dass die Firma Elda über ganz andere Kanäle betrügerische Dinge per Fax durchführt, entzieht sich nicht nur unserer Kenntnis, sondern auch unserer Verantwortung und unserer Einflussnahme.

Nun kommt es, wie es kommen muss: Geschädigte stoßen auf die fragliche Internetseite und ziehen genau die Schlüsse, die dort implizit nahegelegt werden, wenngleich nicht explizit ausformuliert. So trudelte dann heute ein Einschreiben eines Geschädigten bei mir ein: „Mein“ Vertragsangebot wird angefochten; ich werde beschuldigt, den Geschädigten „planmäßig, vorsätzlich und arglistig über den wahren und [vom Geschädigten] erwarteten Inhalt […] getäuscht“ zu haben. Angemessene Worte – aber an den falschen Adressaten. Zu weit ging es mir aber dann, als ich lesen musste, dass der Geschädigte „meine Vorgehensweise nebst Unterlagen an die Zentrale zur Bekämpfung unlauteren Wettbewerbs weitergeleitet habe“. Meine Hand griff zum Hörer.

Die freundliche Dame, die ich am Telefon hatte, gab unumwunden zu, dieses Schreiben an mich adressiert zu haben, „weil das ja so im Internet steht, dass Sie dahinterstehen“. Ich musste mich bemühen, die Fassung zu wahren. Was bringt Leute bloß dazu, einfach alles zu glauben, was im Netz steht – noch zudem, wenn es auf einer Seite steht, die sich geradezu damit brüstet, kein Impressum zu haben, weil sie nicht in Deutschland gehostet würde und damit nicht dem Teledienstgesetz unterläge?

Das Telefonat verlief freundlich, aber im Ergebnis nicht in meinem Sinne. Zwar konnte ich – so glaube ich – einigermaßen meine Rolle in dieser Angelegenheit vermitteln; darauf, mir ebenso schriftlich wie das zuvor verschickte Einschreiben nun aber auch mitzuteilen, dass man nun doch keine Anschuldigungen gegen mich hätte, keine Forderungen gegen mich geltend machen würde und last but not least auch die Wettbewerbszentrale darüber informieren würde, dass es sich hierbei um eine Falschinformation handelt, wollte sie sich dann aber doch nicht einlassen – dafür könne sie die Situation nicht gut genug einschätzen; sie habe letztlich nur deshalb dieses Schreiben an mich gesendet, weil ihr Anwalt ihr gesagt habe, dass sie das tun solle. Au weia.

Nun, so einfach lasse ich das nicht auf mir sitzen. Wer sich von mir Verständnis und Kooperation erhofft, erreicht das mit einer kurzen Mail oder einem simplen Anruf viel einfacher, als mich mit rechtlichen Schritten und hohen Forderungen zu bedrohen. Aus diesem Grund habe ich nun eine schriftliche Stellungnahme angefordert und dafür eine entsprechende Frist gesetzt. Insbesondere gegen Anschwärzungen bei der Wettbewerbszentrale aufgrund anonymer Beschuldigungen habe ich dann doch was einzuwenden. Wo bleibt eigentlich der gesunde Menschenverstand? Es tut mir ja sehr leid, wenn die nette Frau vor einer Antwort auf mein Schreiben erst nochmal ihren Anwalt konsultieren will (der dafür dann ja sicherlich auch wieder eine Rechnung schreiben wird), aber das hätte nun wirklich von Anfang bis Ende alles nicht sein müssen.

• Mail an den Betreiber von verbraucherabzocke.info
• Mail an das geschädigte Unternehmen

Wer an Unix-artige Systeme gewöhnt ist, neigt häufig dazu das Vorhandensein von Manpages einfach vorauszusetzen. Fehlen Manpages fällt das nicht immer gleich auf, aber wenn es auffällt dann meist auf unangenehme Art und Weise, nämlich dann wenn die Manpages gerade gebraucht werden. Manchmal fehlt eine Manpage aber auch gar nicht, sondern wird nur einfach vom System nicht gefunden, das ist dann besonders ärgerlich.

Ich hatte das Problem neulich mal wieder und da ich mich schon öfters darüber geärgert habe, bin ich diesmal der Sache auf den Grund gegangen. Bei Unix kann man sich häufig Ärger ersparen, wenn man den Dingen auf den Grund geht, da die es für sehr viele Probleme schon Lösungen gibt. Wie arbeitet also das Manpage-Subsystem?

Zunächst einmal gibt es analog zur Umgebungsvariable PATH die recht bekannte Variable MANPATH, mit der sich das Manpage-Subsystem sagen läßt, in welchen Verzeichnissen es nach Manpages suchen soll. In einem aktuellen RHEL/CentOS/Fedora glänzt diese Umgebungsvariable aber zunächst durch Abwesenheit. Natürlich kann sie an geeigneter Stelle definiert werden, etwa in .bash_login oder ähnlichen Dateien, aber warum fehlt sie von vornherein und warum werden trotzdem Manpages gefunden?

Das Manpage-Subsystem sucht selbständig einem bestimmen Schema entsprechend nach Manpages. Wird z.B. die Manpage zu einem Programm aufgerufen, das in /usr/local/bin/ liegt, dann wird zuerst in /usr/local/man/ nach der passenden Manpage gesucht. Die Variable MANPATH wird erst nötig, wenn die Manpage zu einem Programm oder einer Datei nicht an einem Ort liegt der in dieser Weise relativ zum Ort der Datei bzw. des Programms ist.

Ein Beispiel aus unserer täglichen Praxis: Nach der Installation von qmail genügt es /var/qmail/bin der Umgebungsvariable PATH hinzuzufügen, die Manpages in /var/qmail/man werden dann automatisch gefunden.

Nun ist aber genau diese relative Lage nicht durchzuhalten, wenn im Dateisystem eine grundlegende Ordnung eingehalten werden soll, wie etwa vom Filesystem Hierarchy Standard vorgeben. Denn es müßte zu jedem Ordner der Programme, Bibliotheken oder Konfigurationsdateien enthält einen Order mit den Manpages an der entsprechenden relativen Position dazu geben. Das Ergebnis wären sehr viele Ordner mit Manpages, die sich über das gesamte System verteilen. Sie alle zu durchsuchen würde relativ lange dauern (auch wenn es auf aktuellen Systemen wohl trotzdem kaum auffallen würde) und wäre reine Resourcenverschwendung.

Hier kommt nun die Datei /etc/man.config ins Spiel. Hier werden zunächst Standard-Pfade an denen viele Manpages abgelegt sind definiert, z.B. MANPATH /usr/share/man. Darüber hinaus können hier auch Abweichungen von dem oben beschriebenen relativen Pfaden definiert werden, sogenannte Mappings. Das Statement MANPATH_MAP /usr/bin /usr/share/man vermittelt dem Manpage-Subsystem, daß es für Programme in /usr/bin/ die Manpages nicht in /usr/man/ suchen braucht, sondern direkt in /usr/share/man/ suchen kann.

Wer viel Software aus den Quellen selbst übersetzt oder sich eigene RPMs baut oder selber Software schreibt, sieht sich vielleicht hin und wieder mit der Frage konfrontiert, wohin Manpages installiert werden sollen. Hier lohnt es sich den einen oder anderen Gedanken auf diese Zusammenhänge zu verwenden, statt immer wieder das Rad neuzuerfinden oder die Aufgabe dafür zu sorgen daß die Manpages auch gefunden werden einfach den Administratoren und Usern zu überlassen. Natürlich fällt auf aktuellen Computern die geringe Performance-Einbuße durch weit verstreute Manpages und Programme nicht mehr auf, diese Überlegungen können also vernachlässigt werden. Bei Embedded-Systemen sieht das natürlich schon wieder anders aus. Und vielleicht legt die eine oder der andere so wie ich auch Wert auf die Eleganz einer guten Lösung.

Tina erklärt auf dasBahnblog.de unterhaltsam den Bahnfahrer-Kodex:

[…] Auch wird dieser ICE weniger von „Ich-fahre-einmal-im-Jahr-Zug-weiß-aber-alles-über-die-Bahn“ Reisenden frequentiert, sondern vielmehr von den Berufspendlern, die sich an den Bahnfahrer-Kodex halten. Es bleiben einem die ewigen Schimpftiraden auf die Bahn erspart und auch das nervige „Das darf doch nicht wahr sein“, wenn der Zugbegleiter die obligatorische 5-Minuten-Verspätung bei der Abfahrt aus dem Hauptbahnhof ankündigt, hört man sehr selten.

Der Bahnfahrer-Kodex beinhaltet auch die Rücksichtnahme auf müde Pendler, die einfach nur in Ruhe mit ihren Ohrstöpseln dösen oder ein Buch lesen wollen. Zum Telefonieren verlässt man das Abteil und die Krankengeschichte von Tante Else wird den Mitfahrern nicht in allen Einzelheiten erläutert. Man sitzt im Abteil versetzt, so dass jeder seine Beine ausstrecken kann: wenn sich dort schon zwei Reisende befinden (der eine am Fenster, der andere am Gang), so akzeptiert man sein Schicksal und wählt den unbeliebten Mittelplatz. […]

Als passionierter Dauerbahnfahrer bin ich damit gut vertraut. Um so ärgerlicher ist es, wenn gerade in den frühen Morgenstunden der Zug von Leuten bevölkert wird, die noch nie vom Kodex gehört haben. Ich gebe offen zu: Mit wochenendheimfahrenden Soldaten, die den Zug quer durch alle Gänge stehend und sitzend bevölkern, habe ich überhaupt kein Problem. Mein Problem sind … die Betriebsausflüge. Im Regelfall sind es nur Frauen. Ich weiß nicht, ob die Männer gleich daheim bleiben oder verglichen zu ihren Mitfahrerinnen einfach in der Menge der Reisenden unerkannt untergehen. Meine Fahrt heute führte mich zu einem Kunden nach Dortmund. Abfahrt in Mainz: 6:18 Uhr. Jeder kann sich denken, dass eine Runde Dösen im Zug angesagt ist. Das ging auch gut – bis Köln. 8 Uhr morgen, ein paar Minuten später. Das Frauengrüppchen machte sich noch vor dem Öffnen der Zwischentür zum Wagen lauthals bemerkbar. Ganz klar: Da war schon vor dem Start Alkohol im Spiel. Ich erinnere daran: 8 Uhr morgens. Binnen Sekunden ist der gesamte Wagen von lebhaftem Geschnatter erfüllt. Kaum sind die Plätze eingenommen, werden die Plastikbecher verteilt und der Sekt geöffnet; sicher nicht die erste Flasche. Am schlimmsten aber ist … das Lachen. Das hysterische Lachen, zwei Oktaven höher als nötig, das sich durchdringend und schmerzhaft den Weg in mein Innenohr bahnt. Und natürlich das Gemecker. Über Alex, den armen Tropf, der die Reise organisiert hat (und schlau wie er ist, nicht in Sicht- oder Hörweite der Damen ist. Bestimmt ist er „krank“ geworden). Ein Tisch, ein Tisch, ich will aber an einen Tisch! Dann können wir Karten spielen! Wieso hat Alex keinen Tisch reserviert? Wieso müssen wir hier sitzen? Oh nein, der Zug fährt ja verkehrtherum! Da wird mir ja ganz schlecht! Da müssen wir uns aber gleich bei Alex beschweren, da hätte er ja mal die Plätze richtigherum buchen können! … und so weiter, und so weiter.

Nach zehn Minuten habe ich es nicht mehr ertragen. Gut, dass das Bordrestaurant nur zwei Wagen weiter war.

Es ist sicherlich nicht die feine Art, über Mitbewerber zu lästern, und es soll auch eine Ausnahme bleiben. Aber was einem unserer Kunden vor wenigen Tagen bei einem anderen Hoster – nennen wir ihn „N“ – passiert ist, ließ mir wirklich die Kinnlade herunterfallen.

Wir haben kein Problem damit, wenn Kunden von uns Server bei anderen Anbietern betreiben und dann nur den Support von uns beziehen. Sicherlich ist das nicht optimal, wenn wir bei echten Problemen keine Möglichkeit haben, z.B. Hardware zu reparieren und auch sonst auf die Debugging-Möglichkeiten des anderen Anbieters angewiesen sind, wenn der Kunde Hilfe braucht, aber wir kommunzieren im Vorhinein klar, was geht und was nicht, so dass es hier eigentlich nie zu Irritationen kommt.

Der Server, den unser Kunde neben einigen anderen bei N hat, machte Probleme. Die genaue Vorgeschichte kennen wir nicht; aus telefonischen Schilderungen konnten wir Unspezifisches entnehmen wie „das Gerät reagiert nur langsam“ (obwohl der Load bei 0 liegt), „Pings gehen mal durch und mal nicht“ … kurz, Symptome, die vieles bedeuten können.

Den Logfiles konnten wir entnehmen, dass der fragliche Server in den letzten Tagen etwa 40 Mal rebootet worden ist – au weia. Wenn ein Reboot ein Problem nicht löst, tut’s ein zweiter in der Regel auch nicht. Aber sei’s drum.

Wir wurden zu Hilfe gerufen, als die Situation die war, dass N dem Kunden mitteilte, den Server rebootet zu haben, der Kunde den Server aber dennoch nicht erreichen konnte. N hat für diese Fälle ein einfaches Schema: Der Server wird in den Rescue-Modus versetzt und dem Kunden das Rescue-Passwort mitgeteilt, damit er sich die Sache selber ansehen kann.

Ich will anmerken, dass ich diese Vorgehensweise – gelinde gesagt – bereits eine Unverschämtheit finde. Der Server ist nämlich ein Mietgerät, das mit von N vorinstallierter Software ausgeliefert wird und ein Webinterface mit sich bringt. Der Kunde hat zu keinem Zeitpunkt am Kernel, an den Netzwerkeinstellungen oder an sonst irgendetwas herumgebastelt, sondern einfach nur Websites über das bereitgestellte Webinterface eingerichtet. Wenn so grundlegende Funktionalität wie die schlichte Erreichbarkeit übers Netzwerk fehlt, ist das aus meiner Sicht daher immer Sache des Anbieters, dies vertragsgemäß bereitzustellen. (Anders sieht der Fall natürlich aus, wenn der Kunde selber ein Betriebssystem installiert oder am bereitgestellten System herumbastelt, zum Beispiel einen anderen Kernel installiert, der nicht funktioniert. Anbieter, die eine solche Freiheit ermöglichen, bieten dann aber typischerweise dafür auch eine Rescue-Konsole. Bei N heißt „Rescue-Modus“, dass man anrufen muss und ein Techniker eine CD einlegt. Von daher muss man auch nochmal anrufen, wenn die CD wieder entfernt werden muss, damit das Gerät normal booten kann. An Rescue außerhalb der Geschäftszeiten ist von daher nicht zu denken.)

Wir hatten nun also Zugang zum Rescue-System des Servers, der nicht mehr per Netzwerk erreichbar war. Die letzte Auskunft des Supports von N lautete: Wir hatten Tastatur und Monitor angeschlossen und konnten verifizieren, dass der Server hochgefahren ist und nun am Login-Prompt steht. Als der Kunde daraufhin anmerkte, dass der Server aber nicht mal per Ping erreichbar wäre, folgte kurzerhand der Rescue-Modus, „damit Sie das wieder in Ordnung bringen können“.

Mein Kollege Matthias brachte mich auf den entscheidenden Punkt: Ich solle mir doch mal die Ausgabe von lspci anschauen; da würde was von einer Intel-Netzwerkkarte stehen. Er meine, sich erinnern zu können, dass da eine RealTek-Karte drin gewesen sei.

Einige Checks in den dmesg-Logfiles später war klar:

Erstens, N hat die Netzwerkkarte ausgetauscht.

Zweitens, N hat dem Kunden aber nicht gesagt, dass sie die Netzwerkkarte ausgetauscht haben.

Drittens, in dem – von N! – installierten Kernel ist überhaupt kein Treiber für die neue Netzwerkkarte vorhanden. Das Gerät kann also überhaupt nicht übers Netzwerk erreichbar sein.

N hat folglich überhaupt nicht geprüft, ob die neue Netzwerkkarte funktioniert. Sie haben es nicht mal geprüft als der Kunde sich explizit darüber beschwerte, dass der Server nicht per Netzwerk erreichbar ist. Stattdessen hat man einfach den Rescue-Modus aktiviert und dem Kunden die Fehlersuche überlassen – wie gesagt, ohne ihm mitzuteilen, dass da jetzt eine ganz andere Netzwerkkarte drinsteckt.

Letztlich konnten wir an dem Problem nicht viel machen, denn der installierte Kernel ist, vorsichtig gesagt, antik. Kurz, für aktuelle Intel-Netzwerkkarten ist da mit einem Treiber nicht viel zu wollen. Unser Support für den Kunden beschränkte sich also eher darauf, ihn darin zu unterstützen, dass N das Problem korrekt löst – und sich vielleicht dann doch auch bitte mal zum Thema „stillschweigend getauschte Netzwerkkarte“ äußern möge.

Das hat N dann schließlich auch getan: Die einzige Möglichkeit sei, einen neuen Kernel zu kompilieren oder die Daten zu sichern und den Server neu aufzusetzen. Offensichtlich war es N aber zu mühselig, einen neuen Kernel zu kompilieren, denn die finale Aufforderung lautete schließlich:

Daher bitten wir Sie, die wichtigen Daten zu sichern, sodass wir den Server neu aufsetzen können. Dies können Sie im Rescuemodus mit dem Programm „WinSCP“ machen, welches so ähnlich funktioniert wie ein ftp-Programm.

Verständlicherweise ist dem Kunden da dann ziemlich der Kragen geplatzt. Immerhin ist bei einem Mietserver die korrekte Funktion der Hardware strikt die Sache des Anbieters, und genauso auch das korrekte Zusammenspiel mit dem ausgelieferten System – sprich, wird die Hardware durch den Anbieter (zumal ohne Rücksprache) verändert, sehe ich es auch als Sache des Anbieters, das installierte Betriebssystem entsprechend anzupassen.

Unnötig zu sagen, dass „die wichtigsten Daten sichern“ nicht einfach ein scp-Befehl gewesen wäre. Immerhin geht es um unterschiedliche Systemuser, deren Daten, Konfigurationsdateien, und schließlich auch noch die Daten der Konfiguration der Web-Administration, von der niemand genau weiß, wo sie liegen und wie man sie so sichern kann, dass man sie woanders wieder einspielen kann. Aber offensichtlich meint N, das manuelle Anlegen von, sagen wir mal, 100 Websites und 1000 E-Mail-Adressen und anschließendes Wiedereinspielen von Backups sei keine Arbeit, das kannman ja mal in der Kaffeepause erledigen.

Nachdem wir den Kunden mit entsprechender Argumentation ausgestattet hatten, war es eine Sache von einer Stunde, bis der Anbieter eine Netzwerkkarte eingebaut hatte, die vom bestehenden Kernel unterstützt wird. Das Gerät läuft seitdem wieder ohne Schwierigkeiten.

Soeben habe ich die erste Version des Perl-Moduls „InternetX“ hochgeladen, mit dem sich die API (Handle-Verwaltung, Domainregistrierung, etc.) über eine „perlige“ Schnittstelle steuern lässt, sowohl als .tar.gz als auch als .src.rpm.

Problematisch war zunächst, dass die InternetX-API bei Domainaufträgen nur eine Rückmeldung im Sinne von „Auftrag angenommen“ liefert und die endgültige Rückmeldung erst im Nachhinein per E-Mail kommt. Wir haben uns daher überlegt, dass es doch ganz praktisch wäre, eine Art Eventliste zu realisieren, um diese periodisch nach zu erledigenden Aufträgen auszuwerten – und dafür eine POP3-Mailbox zu benutzen. Eine Methode eventlist() liefert also den Inhalt einer definierten Mailbox zurück, wobei die Mails hierbei automatisch in ein Hashref geparst werden, das sich leicht weiterverarbeiten lässt. Eine event_delete($uidl)-Methode ermöglicht das „Abhaken“ von Events als erledigt, in dem die betreffende Mail aus der Mailbox entfernt wird – simpel, aber effektiv.

Ich möchte anmerken, dass wir dieses Modul derzeit noch nicht produktiv einsetzen – wenngleich wir das bald umsetzen werden. Sicherlich gibt es hier und da noch etwas zu schleifen, aber letztlich beinhaltet das Modul ohnehin nicht viel eigene Logik, sondern ist in erster Linie Übersetzer zwischen gängigen Perl-Datenstrukturen und den XML-Strukturen, die InternetX verarbeitet. Für Feedback sind wir gerne zu haben; perldoc InternetX liefert außerdem passende Dokumentation mit Beispielen.

Kleine Randnotiz: Das Synchronisieren von Dateien mittels rsync klappt nicht, wenn ein Dateiname einen Doppelpunkt enthält. Dann vermutet nämlich rsync, dass damit eine Angabe in der Syntax host:path gemeint ist. Beispiel, in dem eine Datei namens „a:b“ angelegt wird und nach „c“ synchronisiert werden soll:

$ touch a:b
$ rsync -v a:b c

Effekt: Geht schief, weil „a“ als Hostname betrachtet wird, der nicht aufgelöst werden kann. Dave Dykstra weiß Rat: Wenn man eine Pfadangabe davorsetzt, wobei schon „./“ ausreicht, wird der Doppelpunkt nicht mehr fehlinterpretiert. So geht’s also:

$ rsync -v ./a:b c
a:b

sent 63 bytes  received 31 bytes  188.00 bytes/sec
total size is 0  speedup is 0.00

Wenn wir gegen das Grundgesetz verstossen, weil wir Pädophilen unmöglich machen kinderpornografische Bilder aus dem Internet herunterzuladen, dann nehme ich das in Kauf.

Sagt Thomas Jurk, der Spitzenkandidat der SPD für die Landtagswahl in Sachsen. Gegen Herrn Jurk wurde übrigens schon im letzten Jahr wegen Amtsanmaßung ermittelt, als er, nachdem er von einem Motorradfahrer am Überholen gehindert worden war, jenen kurzerhand mit einer Polizeikelle rausgewunken hat.

Mich persönlich fröstelt es immer ziemlich, wenn einzelne Leute glauben, ihr persönliches Handeln sei in irgendeiner Art und Weise „richtiger“ als das Grundgesetz. Liebe Sachsen, entscheidet weise.

Für selfHOST haben wir vor längerer Zeit Teile des Backends entwickelt, darunter den Export von Zonen aus der Datenbank ins DNS-System. Besondere Beachtung erhielten hierbei Umlautdomains: In der Datenbank werden diese „ganz normal“, also mit Umlauten, abgespeichert; beim Export in die DNS-Daten kommt das Perl-Modul IDNA::Punycode zum Einsatz.

Das Modul stellt eine Funktion „encode_punycode“ bereit, die den Punycode-String eines Strings mit UTF8-Werten zurückliefert. Davor musste dann noch der Präfix „xn--„. Eine entsprechende Zeile Programmcode sah nun so also etwa so aus:

$domain = 'xn--' . encode_punycode($domain);

(In Wirklichkeit ist es etwas aufwendiger, weil die einzelnen durch Punkt getrennten Teile eines vollständigen Hostnamens einzeln kodiert werden müssen, aber das sei hier mal dahingestellt.)

Nach Migration eines Teils der Software (die DynDNS-Updates wurden aus Performancegründen vom normalen Webserver separiert) auf einen separaten Server zeigten sich plötzlich merkwürdige Phänomene: Einzelne Domains waren plötzlich im DNS nicht mehr erreichbar, das Gros aber schon. Schnell kamen wir darauf, dass nur Umlautdomains betroffen waren – hier dann aber auch nicht alle. Wie konnte das sein? Die gesamte DynDNS-Update-Routine war ohne jede Änderung 1:1 auf das neue System kopiert worden …

Nach weiteren Analysen stellen wir festen: Wird die DNS-Zone durch den Webserver (altes System) neu geschrieben, zum Beispiel weil jemand DNS-Einträge webbasiert von Hand ändert, wird die Zone korrekt geschrieben. Wird die DNS-Zone durch den DynDNS-Server (neues System) neu geschrieben, tragen alle Umlautdomains einen doppelten Präfix. Von dieser Erkenntnis war es dann nur noch ein kleiner Schritt, um IDNA::Punycode als den Schuldigen auszumachen: Die Funktion setzt nun selbstständig den Präfix davor.

Der Autor bemerkt in der man page:

According to RFC 3490 the ACE prefix „xn--“ had been chosen as the standard.  Thus, „xn--“ is also the default ACE prefix.  For compatibility I’m leaving idn_prefix() in the module.  Use „idn_prefix(undef)“ to get the old behaviour.

Nun, ist ja schön, dass er einem nun diese Arbeit abnimmt. Nur: Schon mal was von Abwärtskompatibilität gehört? Wenn ich eine Funktion gemäß der Dokumentation einsetze, erwarte ich, dass jene auch nach dem x-ten Update bei identischem Aufruf auch noch ein identisches Ergebnis liefert. Wie wär’s zum Beispiel hiermit gewesen:

• idn_prefix() wird als Funktion eingeführt und ermöglicht einem, mit einer einzigen Zeile Aufwand überall automatisch einen Präfix zu setzen. Benutzt man idn_prefix() nicht, verhält sich das Modul dem bisherigen Default entsprechend. Oder wie wär’s hiermit:
• encode_punycode() bleibt unangetastet, und es wird eine neue Funktion encode_punycode_with_prefix() eingeführt. Diese berücksichtigt die mittels idn_prefix() vorgenommene Einstellung, die dann meinetwegen auch standardmäßig auf ‚xn--‚ stehen kann.

So aber wurde die Abwärtskompatibilität (ohne Not!) gebrochen und zog auf diese Weise unnötigen Zeitaufwand für Support, Analyse und Fix nach sich. Schade!

Auf unseren internen System evaluieren wir derzeit den Einsatz von Greylisting mittels qmail. Am Beginn der Suche stand hier zunächst, einen geeigneten Patch zu finden. Genauer gesagt sind es gleich mehrere. Um das Ergebnis vorwegzunehmen: Die finale Struktur sieht wie folgt aus …

1. qmail-smtpd wird derart gepatcht, dass es bin/qmail-envelope-scanner aufruft. Der Patch hierfür ist klein und überschaubar und agnostisch, was den eigentlichen die Header beurteilenden Vorgang betrifft. Er sorgt lediglich dafür, dass der Exitcode von qmail-envelope-scanner ausgewertet wird und dementsprechend qmail-smtpd dann einen temporären oder permanenten Fehler zurückliefert. Einen Autor für diesen Patch habe ich nicht finden können; Jeremy Kusnetz hat offensichtlich die „beste“ Version aus verschiedenen Schnipseln zusammengesetzt, die auf der Mailingliste herumgingen.
2. Der eigentliche qmail-envelope-scanner stammt von Martin Dempsey. Martin hatte zunächst local_scan als Greylisting-Erweiterung für Exim entwickelt. Als Standalone-Tool war es aber nicht weit davon entfernt, auch von qmail aus genutzt zu werden. Der qmail-envelope-scanner ist nur ein Wrapper (33 Zeilen) um das eigentliche local_scan herum.

Die aus meiner Sicht praktikabelste Zusammenstellung der Patches stammt schließlich von Bill Shupp. Wer hier weiter nach unten scrollt, findet dort den Abschnitt „EXPERIMENTAL: greylisting patch“. Er fasst die beiden obigen Patches zusammen mit einem Patch für das Makefile von netqmail-1.05 zusammen.

Bei uns waren noch zwei Änderungen nötig, die jedoch spezifisch für das von uns eingesetzte CentOS sind:

• Der Verweis auf /usr/lib/libmysqlclient.a im Makefile muss auf /usr/lib/mysql/libmysqlclient.a geändert werden, da die Bibliotheken bei CentOS in diesem Unterverzeichnis liegen.
• In conf-cc muss noch ein „-lssl“ ergänzt werden, da die libmysqlclient bei CentOS mit SSL-Support kompiliert wurde und sich von daher nicht benutzen lässt, wenn nicht auch gleichzeitig gegen die OpenSSL-Library gelinkt wird.

Ansonsten müssen nur noch Bills Anweisungen befolgt werden: Es sollte ein periodischer Job eingerichtet werden, der veraltete Einträge aus der Datenbank entfernt werden, und es muss eine Tabelle für die Daten angelegt werden.

Die Konfiguration kann in dieser Version sehr praktisch – Dank an Joshua Megerman – durch Umgebungsvariablen geregelt werden, für die ich empfehlen würde, sie in /service/qmail-smtpd/run unterzubringen. Bei dieser Gelegenheit würde ich auch die Expire-Werte anpassen, da mir ein erstes Akzeptieren eines Tripels erst 55 Minuten nach dem ersten Zustellversuch doch reichlich spät erscheint:

export MYSQLHOST="..."
export MYSQLUSER="..."
export MYSQLPASS="..."
export MYSQLDB="..."
# minutes until email is accepted
export BLOCK_EXPIRE="5"
# minutes until record expires
export RECORD_EXPIRE="500"
# days until record expires after accepting email
export RECORD_EXPIRE_GOOD="36"
export LOCAL_SCAN_DEBUG="1"

(Hier würde sich empfehlen, die Zugangsdaten zu MySQL in einem separaten Shellscript auszulagern, das dann sowohl vom rund-Script als auch vom Aufräumjob eingebunden wird. Ich hab’s nicht so gern, wenn Daten auf zig Orte verstreut werden.)

Erstes Ergebnis: Nur rund 1,5 Prozent aller Zustellversuche werden wiederholt. Es ist also davon ausgehen, dass die restlichen 98,5 Prozent in erster Linie Spammer sein werden. Wir bleiben dran.