Anonymisierter Screenshot von 14:31 Uhr:



Der Server relayed Mails „ins Internet” via dediziertem SMTP-Gateway, welches in einer anderen Stadt steht. Die Standorte sind via privatem WAN verbunden. Man beachte:

1. Die Anzahl der Nachrichten in der Warteschlange (rechts unten).
2. Den Absendezeitpunkt der ersten Nachricht (rechts oben).
3. Die Größe der Nachricht, die derzeit zugestellt wird (oben Mitte) - und ja, alle Nachrichten, die er auszuliefern versucht hat, waren „relativ groß” und es waren alles Retries von großen Nachrichten.

Was schließen wir daraus, wenn die gesamte „active queue” mit sowas zugeballert ist? Genau, klassischer Fall von „congestion” bzw. „saturation”. Laut Auskunft des Verantwortlichen lag es am fehlerhaft funktionierenden Bandbreitenmanagement. Ursächlich vielleicht richtig. Daß das eigentliche Problem die Fehlkonfiguration der Exchange-Server war (man hätte die Anzahl der „delivery slots” für große Nachrichten limitieren müssen, um dieses Phänomen, i.e. Füllen der Queue mit erneuten Zustellversuchen von großen Nachrichten, die höchstwahrscheinlich wieder in einen Timeout laufen, zu verhindern, aber wahrscheinlich ist Exchange für sowas zu doof), davon war keine Rede. Funktioniert unter normalen Umständen ja schließlich auch problemlos. Und kann auch garantiert nie wieder vorkommen („eins ausrufezeichen elf ”).

Wieso lasse ich mich eigentlich immer wieder mit solchen Aussagen abspeisen? Ich meine, ich weiß es doch eigentlich besser. 300k Mails am Tag (auf meinen Kisten) sprechen halt eine deutliche Sprache. Muß an der Sympathie liegen, die ich für die Verantwortlichen empfinde. Die stammt übrigens noch aus dem Jahr 2002.

Nachtrag: Ich sollte die Reports von postfix-logwatch auch mal lesen. 634k am Tag, seit einer Woche nicht unter 600k.

Nachdem ich mir heute morgen die Mühe gemacht und mich drei Minuten lang mit der Dokumentation zu apt-ftparchive(1) auseinandergesetzt habe, biete ich die Pakete in meinem persönlichen Repository für Debian/etch jetzt auch mit digitaler Signatur an. Die Anleitung habe ich aktualisiert, eine englische Version findet sich hier. Und weil das sonst sinnlos wäre:

INTERNATIONAL VERSION: My personal archive of backported or modified packages for Debian/etch is now available here.

Ich wünsche Euch allen ein frohes und und langes Wochenende!

Ohne Worte:



Und wieder eine neue Tastatur wegen, äh, „Kaffeeschaden” fällig!

Nachdem ich hier ja schon die postfix-Pakete für Debian/etch (aka stable) mit dem stress-Patch neu gebaut hatte, habe ich das jetzt auch mal für den Backport von 2.4.5 getan. Zu finden wie üblich im Repository.

Ihr kennt das, die normalen Disclaimer gelten - und so. Vor allem „und so”!

Gefunden in der Signatur von Ralf Hildebrandt:



Wer es etwas ernsthafter mag: Qmail bugs and wishlist.

Euch allen ein wunderschönes, erholsames Wochenende.

Der Titel sagt alles - ich habe dk-filter in mein Repository geworfen und die für Spamassassin benötigte Version von libmail-domainkeys-perl gleich mit.

Die üblichen Disclaimer gelten!

Angeblich ist es ja legitim, das eigene Blog als Notizzettel zu verwenden. Quae cum ita sint schreibe ich jetzt kurz mal für mich auf, wie man mit mehr als einem Upstream routet. Zwei mögliche Anwendungsszenarien:

1. Server mit zwei Netzwerkkarten, die beide mit dem selben Router bzw. Switch verbunden sind: Bei zwei Default-Routen wird eine davon per Zufall gewählt, bei einer Default-Route werden Pakete über das Interface, auf dem die Default-Route liegt, mit falsche IP-Adresse verschickt, wenn zuvor das andere Interface angesprochen wurde, die Pakete also mit dessen Absenderadresse generiert wurden.
2. Einwahl auf einer Leitung mittels ISDN und gleichzeitig mit PPP, also Mehrkanalrouting für Arme.

Ich dokumentiere hier den ersten Fall und mache die folgenden Annahmen:



Dann definiert man als erstes zwei zusätzliche Routingtabellen mit einem, äh, „griffigen” Namen:



Das hat den Hintergrund, daß man sonst immer mit den Nummern hantieren muß. So dann konfiguriert man die Interfaces,



macht die Interfaces an,



legt die beiden separaten Routing-Tabellen fest,



definiert die Routing-Policy,



und füllt zuletzt die Default-Routingtabelle:




Genau nachlesen kann man das wie gehabt bei lartc.org an dieser und dieser Stelle.

Fans der Serie „Dr. House” wissen übrigens, daß „naughty girls” 17 Jahre und sechs Monate alt sind, rote Unterwäsche tragen und seit 5 Wochen keinen Freund mehr, dafür aber eine Spore im Kopf haben.

Nachdem ich ja unter anderem hier und hier schon Pakete in mein kleines Repository geladen hatte, gibt es heute Nachschub - sozusagen das „Wien-Update”, in Gedenken daran, was hätte sein können. Neu sind:

• libdkim2 und dkim-filter, Version 2.0.2, ein Milter für die Digitale Signatur von Nachrichten mittels DKIM
• libmail-dkim-perl, Version 0.28, kann jetzt auch mit „v=”-Tags im DKIM-Signature-Header umgehen
• slrn 0.9.8 mit Unicode-Support

Wie üblich gilt: Wenn es Eure Rechner explodieren läßt, will ich damit nichts zu tun haben.