Beim Lesen der Überschrift werden sich viele Leute nur „WTF?” denken - dürften die meisten doch davon ausgehen, daß ihre Installation von amavisd-new, wenn sie denn einen Virenscanner benutzen, selbigen auch nur einmal auf jede ankommende Mail loslässt. Normalerweise ist das auch so. Jetzt gibt es aber Situationen, in denen man die ganze Mail braucht, um sie dem Scanner vorzuwerfen, z.B. die Sanesecurity-Signaturen, was man folgendermaßen erreichen kann:



Leider führt das dazu, daß einige Funktionen nicht mehr vernünftig arbeiten, unter anderem das Blocken von Attachments nach Typ oder der Bounce Killer. Also gehen viele den Weg, oben genannten Wert doch auf seinem Default zu belassen und fügen statt dessen in die Map @keep_decoded_original_maps folgende Zeile ein:



Damit hebt amavisd-new die komplette Mail auf - man hat also einen funktionierenden Bounce Killer, funktionierendes Attachment-Blocking und Sanesecurity-Signaturen. Dummerweise scannt der Virenscanner die Mail aber jetzt effektiv zweimal: Einmal die im Original erhaltene Mail und einmal deren einzelne Teile. Um das zu umgehen kann man ganz einfach die Definition des Virenscanners verändern:



Gerade in hochvolumigen Setups dürfte das nochmal einiges an Performance-Zugewinn bringen.

Die Sonne scheint, ich habe zwei tolle CDs mit Chopin-Nocturnes gerade auf meinen MP3-Player kopiert und werde das tolle Wetter jetzt ausnutzen, um Skaten zu gehen

Kurze Durchsage: Mich regt diese dem neudeutschen entlehnte Grußformel auf:



Das klingt wirklich dämlich. Und, was schlimmer ist, es wirkt anbiedernd.

Ich mag Filme von David Lynch: Man versteht die ersten zwanzig mal nur die Hälfte des Films und hat auch beim vierzigsten Mal noch das Gefühl, daß einem etwas Wichtiges entgeht, aber ich finde sie trotzdem toll. Auch und vor allem, weil sie so surreal anmuten. Was ich dagegen überhaupt nicht schätze, ist wenn sich in meinem Berufsleben Anspruch und Realität zueinander surreal verhalten - und glücklicherweise ist die Firma, in der ich derzeit arbeite, weit davon entfernt, mit solchen Problemen kämpfen zu müssen, egal ob in der IT oder in anderen Bereichen des Unternehmens. Umso amüsanter ist es, wenn ich dann von anderen Firmen mitbekomme, wie die Dinge dort manchmal gehandhabt werden.

Eine besonders, äh, „interessante” Geschichte habe ich gestern erlebt - und zwar mit einer richtig großen Bank. Einer wirklich großen. Einer, die jeder von Euch kennt - und deren Name, das sei hier dazu gesagt, weder mit „D”, „N” oder „S” anfängt. Zwischen besagter Bank und uns gibt es schon seit längerem eine Kooperation, die auch den Austausch kleiner Datenmengen beinhaltet. Damit man dort nicht auf Mails angewiesen ist, besteht zwischen uns und der zentralen IT dieser Bank, deren Netzwerk hier den Namen PrivateNet tragen soll, schon seit längerem eine VPN-Verbindung. Auf unserer Seite ist der PrivateNet-Tunnel ganz normal in einer dedizierten, hochverfügbaren DMZ auf zwei redundanten VPN-Routern terminiert, klassische Netztrennung, Zugriff aus dieser DMZ gibt es nur auf gesondert gesicherte weil eben für den Datenaustausch mit externen Partnern vorgesehene Server. Sowohl unsere VPN-Kisten als auch die Datenaustausch-Server stehen natürlich nicht bei uns im Keller (Büroraum in München ist viel zu teuer für solche Vorhaben), sondern in einem externen Rechenzentrum, komplett mit Sicherheitsmaßnahmen, die Panzer abwehren können sollen und mehrfach redundanten Anbindungen an Strom und „Internet”. Soweit ist nichts unüblich, aber bei der Beschreibung fällt vielleicht schon auf, daß ich mehrmals Worte wie „redundant” oder „hochverfügbar” verwendet habe - sprich, die Chancen, daß diese Anbindungen jemals ausfallen, sind recht gering (und daß unsere Konzepte nicht nur in der Theorie funktionieren wissen wir, weil wir mindestens einmal pro Jahr im RZ einfallen und dort nach Lust und Laune Kabel herausrupfen. Na ja, nicht ganz so, aber ihr ahnt, worauf ich hinauswill: Failover-Testing halt). Und so könnte eigentlich auch alles gut sein.

Ist es aber nicht. Seit kurzem besteht besagte Bank darauf, daß wir die Anbindung an sie nicht mehr über VPN-Tunnel vornehmen. Zum einen sei das zu unsicher und zum anderen könne man ja die Verfügbarkeit nicht gewährleisten. Deswegen werden wir nun mehr oder weniger dazu „ermuntert”, die Anbindung auf eine einzelne Business-SDSL-Strecke umzustellen. Wer jetzt „WTF?!?” denkt, dem geht es genauso wie mir, die IT unseres Partners jedoch versteht da wenig Spaß.

Gestern also hatte ich die Gelegenheit, ein Gespräch (zwar nur unsere Seite, aber das war vielsagend genug) zwischen dem bei uns für externe Verbindungen zuständigen Mitarbeiter und seinem Pendant bei PrivateNet mitzubekommen. Und plötzlich wundert mich nichts mehr: Die IT dieser wirklich, wirklich großen Bank hat anscheinend noch nie etwas von RFC 5737, ja, noch nicht mal was von RFC1918 gehört. Die Liste der IP-Adressen, die man uns als Transfernetze angeboten hat, liest sich wie das „Who is Who” der großen, vor dem Internet-Boom vergebenen Allokationen. Auf die vorsichtige Frage meines Kollegen hin, ob besagte Bank diese IP-Adressen denn auch alle besitze, wurde ihm versichert, das sei kein Problem, innerhalb des PrivateNet seien die meisten der angebotenen IP-Adressen routebar und eindeutig, man arbeite ja professionell.

Manchmal besteht zwischen Selbstwahrnehmung und Realität eben eine wirklich ausgeprägte Dichotomie. Ich glaube, der Kollege hat besagte Bank dazu bekommen, die Adressen für die Verbindung zu uns in den RFC1918-Space hinein zu NAten. Und das sollte man sich jetzt wirklich mal auf der Zunge zergehen lassen

Man hat mich einmal beschuldigt (das war glaube ich nach einer Party in der Erziehungswissenschaftlichen Fakultät. Junge Dinger, die Grundschullehramt studieren. Da kriegt man als Kerl den freien Eintritt und den Getränkegutschein. Verkehrte Welt und so. Nach dazu keine geschlossene Angelegenheit wie z.B. die Parties bei den Tiermedizinerinnen, wo man nur reinkommt, wenn man jemanden kennt!), daß für mich ein Tag nur dann gut anfängt, wenn ich mich schon direkt nach dem Aufwachen am Unglück anderer Leute erfreuen kann.Das ist natürlich Käse, denn die Qualität meines Tagesanfangs misst sich, wie ich bereits erwähnte, an der Menge von Speck und Eiern, die ich noch im Kühlschrank habe. Wenn obige Anschuldigung aber richtig gewesen wäre, dann wäre das Aufstehen in den letzten Tagen eine großartige Sache gewesen. Oder genauer: Seit dem 15. April. Denn der 15. April war der Tag, an dem das Entwickler-Team hinter dem OSS-Virenscanner ClamAV alle Versionen vor 0.95 lahmgelegt hat. Rein technisch geschah das durch ein einfaches Signaturupdate, wie sie mehrmals täglich stattfinden - nur diesmal eines, das die alten Versionen nicht vertragen haben:



Man muß an dieser Stelle übrigens die Eleganz des ganzen bewundern - ist doch obiges gleich das beste Beispiel dafür, warum sich die Entwickler zu diesem Schritt entschlossen haben. Aber weiter im Text: Die ClamAV-Entwickler halten es schon seit langem so, daß ihr Scanner immer dann überhaupt nicht mehr funktioniert, wenn seine Datenbank kaputt ist. Und da der Update-Prozess die Signaturen nicht selbst sondern über einen Reload des Scanners verifiziert, ist das Desaster perfekt: Die neuen, unverdaulichen Signaturen befinden sich auf der Platte, es gibt keine alte Kopie, auf die man einfach zurückspringen könnte (es sei denn, man macht selbst Backups) und ClamAV stellt die Arbeit ein. Aber nicht nur ClamAV selbst, sondern auch alle Produkte, die gegen die alten Libraries gelinkt sind.

Und dann knallt es natürlich. Und wie. Um mal zwei typische Szenarien zu nennen:

1. Wenn man amavisd-new benutzt und dort den dämonisierten Scanner des ClamAV-Projekts mit Namen „clamd”, dann wird amavisd-new nach dem finalen Signaturupdate jede einzelne Mail mit einem temporären Fehler abweisen. Erste Berichte sprechen von „deliverability rates”, die plötzlich um drei bis fünf Prozent gesunken sind - und das, obwohl mir auf Anhieb kein größerer ISP einfällt, der auf seinen Gateways clamav einsetzt.
2. Im Bereich der HTTP-Proxy-Filter gibt es ja z.B. HAVP oder DansGuardian. Beide kann bzw. muß man gegen die „libclamav” linken - und ist die zu alt, dann stellen auch diese beiden Programme ihren Dienst ein.

Der Donnerstag/Freitag (je nach Zeitzone) dürfte für einige Leute wirklich interessant geworden sein. Wollen wir nur hoffen, daß sie an diesen Tagen keine sonstigen Notfälle hatten Und man muß die Entwickler auch für ihr Timing bewundern: Die meisten Leute in Europa dürften erst am Freitag mitbekommen haben, daß ihre Mailserver stehen. Das heißt nicht nur, daß der mögliche geschäftliche Schaden minimiert wurde (betrifft ja nur einen WOchentag, und man hat das ganze Wochenende Zeit, das zu fixen), sondern auch, daß sie damit genau die Leute verärgert haben, die in letzter Instanz bestimmen, welche Virenscanner eine Organisation einsetzt (Reminder hin, Reminder her, wenigstens auf der Seite, die ein veralteter ClamAV immer zur Informationssuche empfiehlt, hätte man ja ganz oben in roter Farbe eine Warnung einfügen können, wenn man sich schon darauf beruft, seit sechs Monaten zu informieren!).

Eigentlich wollte ich in obigem Absatz jetzt noch „Man kann sich auch eine Handgranate nehmen, den Stift ziehen und sich das Ding in die Hose schieben. Hat die gleiche Auswirkung wie die Killersignatur: Man tritt mit eine Knall ab!” schreiben. Das wäre dann nicht nur ein für mich ganz und gar typischer Vergleich gewesen, sondern hätte auch die typischen Stimmen (äh, „Stimmung”) wiedergegeben, die ich im Laufe des Tages mitbekommen habe. Da meint z.B. Alexander Wirt, einer der fähigsten Linux-Menschen, die ich kenne:



Oder beispielsweise Marc Haber (der als exim4-Maintainer einen verdammt guten Job gemacht hat):



Viele andere haben dann auch - korrekt - argumentiert, daß auf vielen älteren Distributionen neuere ClamAV-Pakete nichtmal kompilieren (bzw. noch schlimmer, daß nichtmal ./configure durchläuft). Und im Prinzip haben sie damit auch recht. Aber so ein kleines bißchen muß man sich die Entwickler dann doch mal anhören. Da schreibt Edwin Török zum Beispiel:



Und man sagt eben immer wieder - und viele Leute stimmen da zu - daß man ja wirklich schon vor sechs Monaten informiert hat. Wer also keinen Ärger hätte haben wollen, der hätte einfach am 14. den freshclam-Dämon stoppen können. Ebenso ist es richtig, daß alle alten Versionen echte Bandbreitenschweine waren - auf der clamav-mirrors-Mailingliste gab es mehr als nur einmal echt ANGEPISSTE Mirror-Betreiber, die das Pech hatten, einmal ein Signatur-Update verpasst zu haben, und deren Mirror-Server dann stupide von alten freshclam-Versionen beharkt wurden.

Man kann aus der ganzen Geschichte Lehren ziehen: Wenn man OSS-Prjekte entwickelt, die für ihr korrektes Funktionieren darauf angeweisen sind, sich regelmäßg Code nachzuladen, dann sollte man sich schon bei der Entwicklung dieser Update-Mechanismen darüber Gedanken machen, wie man solche Szenarien abdeckt. Das kann man ganz einfach machen und eine MOTD in einen DNS-TXT-RR verpacken (damit habe ich jetzt wieder etliche Leser abgehängt, oder?), die dann bei Bedarf in den Logs erscheint, kombiniert mit einer Versionierung der Update-Schemata, so daß man auch alte Clients noch unterstützen kann (für die muß es ja dann keine neuen Signaturen mehr geben). Ebenso dürfen solche Schnitzer wie die fehlende Ankündigung der EOL auf der FAQ-Seite einfach nicht passieren. Aber auch Joe Sysadmin sollte sein Fett weg kriegen: Wenn man für ein System verantwortlich ist und weiß, daß es da Software gibt, die sich häufig ändert, dann muß man eben in den sauren Apfel beißen und die Ankündigungs-Mailinglisten dieser Projekte abonnieren.

Ich selbst habe zu dem Thema keine ausgeprägte Meinung - bei mir lief überall mindestens die 0.95.3, ich war also nicht betroffen, und ich kann beide Seiten verstehen. Gefreut habe ich mich aber über das ganze Chaos schon etwas. Da macht das Aufstehen doch gleich viel mehr Spaß (ich schätze, irgendwas ist schon dran gewesen an der Eingangs erwähnten Behauptung - oder?)!

Und das nächste Mal werde ich wohl am 5. Mai mit einem Grinsen erwachen. Nur wird es dann bei denen, die Probleme bekommen, ungleich schwieriger sein, selbige zu debuggen. In diesem Sinne - schönen Sonntag noch.

Anteil der Mails, die über die Osterfeiertage via IPv6 eingeliefert wurden: 10%.

Mühsam nährt sich das Eichhörnchen.