Einträge von Sven Grounsell

Nein, das wird kein Beitrag zum Spieleklassiker GTA2, sondern zu unserem just abhanden gekommenen Bundespräsidenten Horst Köhler.

Eines Vorweg: Ich enthalte mich bewusst und nachdrücklich einer Beurteilung seines Wirkens als Bundespräsident, sofern es nicht unmittelbar mit seinem Rücktritt bzw. der vom ihm selbst postulierten Begründung dafür zu tun hat.

Laut Spiegel Online führt er als Grund an, dass die Vorwürfe gegen seine Äußerungen, die er in unmittelbarem Kontext zum Bundeswehreinsatz in Afghanistan abgelassen getätigt hat, Respekt vor dem "höchsten Staatsamt" vermissen ließen.

Aha? Offenbar hat das nichts mit mangelndem Respekt vor diesem Amt zu tun, sich meiner Ansicht nach feige, mit eingekniffenem Schwanz wie ein begossener Pudel zurückzuziehen, nur weil die Leute da draußen sowas böses und [gar nicht] Abwegiges über ihn sagen.

Entschuldigung, Herr Köhler, aber Sie wurden in dieses "höchste Staatsamt" gewählt, weil die entsprechenden Menschen darauf vertraut haben, dass Sie die nötige Kompetenz, Kraft und Würde besitzen, dieses Amt auszufüllen. Und Sie mussten sich dieser Verantwortung bewusst sein, als Sie die Wahl angenommen haben.

Ihre heutige Reaktion allerdings legt den Verdacht nahe, dass Sie den nötigen Respekt vor diesem höchsten Staatsamt vermissen lassen, wenn Sie sich aus so selbstsüchtigen Gründen aus der Verantwortung stehlen. Wer hat je behauptet, dass es einfach sei, "an der Spitze" zu stehen, dass alle Ihnen und Ihren Worten kritiklos zu Füßen liegen werden? Von einem so hohen Würdenträger (man beachte das enthaltene Wort "Würde") erwarte ich ein gewisses Grundmaß an Gelassenheit und Souveränität (es heißt nicht umsonst "der Souverän"). So einen peinlichen Anlass hatte ich nicht erwartet, der mir die umfassende Bedeutung des Wortes "Fremdschämen" verdeutlicht.

Die Ironie an der Sache: Sie haben heute ein unerträgliches Maß an Inkompetenz für dieses Amt an den Tag gelegt, in der Art, wie Sie von Ihrem Amt zurückgetreten sind und damit im Grunde die einzig sinnvolle Konsequenz daraus gezogen haben. Da manifestiert sich beim Ausformulieren ein wahres Henne-Ei-Problem!

der wollte eine Reise machen.

Dazu flog er im Flugzeug ein wenig durch die Welt und stieg letztlich in Amsterdam Schipol um für seine letzte Station, Detroit, USA. So weit so unproblematisch.

Dumm nur, dass dieser Nigerianer, wie wir wohl mittlerweile alle wissen, entschied, sich mit Sprengstoff zu bekleiden. Soll dem Hörensagen nach in den letzten Jahren in gewissen Kreisen schwer in Mode sein.

Das mit der Mode hat sich hier und da schon rumgesprochen, und weil das die meisten Menschen nicht so toll finden, wurde in den letzten 8 Jahren viel unternommen; es wurde eine Unmenge Energie in neue Gesetze, höhere Sicherheitsstandards und weniger Freiheit und Demokratie gesteckt. Es gab so lustige Ideen wie Totalüberwachung, Zensur, Gängelung und, man glaube es kaum, irgendwer hat sogar etwas erfunden, was den meisten Menschen heute als "Nacktscanner" bekannt ist.

Und Letzterer wurde als Konsequenz aus den vorgenannten Maßnahmen unter großem Aufsehen u.a. im besagten Amsterdamer Flughafen Schipol installiert. Bis hierhin muss man das als mündiger Bürger nicht gut finden, mag das aber noch irgendwo begreifen können, vom blinden (oder profilierungs-getriebenen?) Aktionismus nicht näher genannter Mitglieder der letzen Bundesregierung als treibende Kraft dahinter einmal abgesehen.

Was mir aber nicht in den Kopf will:

Wie hat der Mann das geschafft, unbehelligt bis nach Detroit zu gelangen?

a) Er stand auf der Liste der terrorverdächtigen Personen, die die USA führen, das hatte aber offenbar keinerlei Auswirkungen darauf, dass er frei in die USA einreisen konnte - welchen Sinn hat diese Liste dann?

b) Schipol ist wie gesagt einer der Flughäfen, die mit diesen Nacktscannern ausgestattet sind. Seit Mai 2007. Mangelnde Erfahrung im Umgang mit diesen Geräten gilt hier also nicht als Ausrede.

Es ist natürlich das gute Recht dieses Mannes, der Durchleuchtung mit dem Nacktscanner zu widersprechen. Ob er davon gebrauch gemacht hat, ist mir allerdings nicht bekannt, erscheint jedoch sehr wahrscheinlich. Nun hätte er dann aber doch, in Konsequenz zu dem Brimborium der letzten Jahre, einer herkömmlichen Sicherheitskontrolle unterzogen werden müssen, erst recht, wo er als Terrorverdächtiger geführt wird. Und dort hätte man den kleidsamen Sprengsatz dieser Größenordnung definitiv finden müssen. Dass es nicht passiert ist, und dass der Sprengsatz nicht gefunden wurde, stellt den Sinn dieser Geräte meines Erachtens komplett in Frage.

Warum haben all diese Maßnahmen nicht gegriffen? Waren diese Maßnahmen gegen die Freiheit im Namen der Terrorbekämpfung eine Farce? Standen eigentlich ganz andere Ziele Pate dafür, und die Anschläge waren nur willkommenes Deckmäntelchen? Ist deshalb das Greifen der Maßnahmen gegenüber den eigenen Bürgern deutlich besser sichergestellt als gegenüber denen, die als Grund dafür herhalten müssen?

Fragen über Fragen - auf schwäbisch müsste man dem Ganzen wohl nachsagen, es habe ein "G'schmäckle"

Update: da Heise nun berichtet, Schipol wolle jetzt erst Nacktscanner testen, möchte ich beispielhaft diesen Link der Süddeutschen anbringen, um meine Behauptung zu untermauern, dass Schipol derartige Geräte bereits seit Jahren einsetzt.

Wenn Seahorse sich weigert, den privaten SSH-Key zu laden, obwohl er unter ~/.ssh/id_dsa oder id_rsa liegt und laut Dokumentation automatisch geladen werden sollte, und auch ein Import fehlschlägt mit der Meldung, der Schlüssel läge im falschen Format vor, dann liegt das vielleicht daran, dass der öffentliche Schlüssel nicht auch dort liegt oder falsch benannt ist.

Gemeine Sache, die einen viele Nerven kosten kann...

Hier war ja mal wieder in der Tat länger nichts zu lesen von mir.

Ein Grund dafür war, dass ich mich in den letzten Monaten einem guten Freund beratend zur Seite gestellt habe, dessen Ansinnen es war, ein Forum mit angeschlossenem Chat auf die Beine zu stellen.

Natürlich nicht irgendein Forum, denn Foren gibt es zu allem Möglichen wie Sand am Meer im Netz. Aufgrund von Erfahrungen und Erlebnissen im engeren Familien- und Bekanntenkreis sollte es eine Anlaufstelle für Missbrauchs- und Gewaltopfer, sowie deren Angehörige werden.

Das ist natürlich ein großes und vor allem sensibles Thema, das sowohl menschlich, rechtlich, als auch technisch eine sehr besondere und wohldurchdachte Behandlung erfordert.

Schon in der anfänglichen Planungsphase wurde klar, dass es weder möglich noch gewollt ist, über diese Plattform therapeutische, geschweige denn medizinische Dienste für die Betroffenen anzubieten, denn dazu würden Geld, Qualifikation und Personal fehlen. Gewollt ist es auch deshalb nicht, weil kein gravierender Mangel herrscht an ebendiesen Diensten, lediglich der Weg dorthin ist vielfach nicht ersichtlich.

Der tatsächlich existierende Mangel in diesem Themenbereich liegt eher da, dass Betroffene und Angehörige oft keine Plattform haben, bzw. finden, wo sie sich ungehindert austauschen können. Wo sie außerhalb des therapeutischen Rahmens Erlebtes erzählen und verarbeiten können, wo sie sich nicht als das herausstechende Opfer fühlen müssen, weil es hier anderen genauso geht, wo sie sich Rat von betroffenen und nicht-betroffenen (auch die sind wichtig) Menschen holen können, und wo sie trotz ihrer oft als "Macke" interpretierten körperlichen und psychischen Folgen immer respektvoll behandelt werden. Es stellte sich heraus, dass wir das Forum an genau dieser Stelle als Angebot verstanden wissen wollten.

Nachdem das klar war, ging es daran, wie das technisch realisiert werden kann - auch die Frage, ob ein Forum und ein Chat überhaupt die geeignete Grundlage dazu bilden, wurde diskutiert. Technische Machbarkeiten mussten abgeklärt und teilweise auch langwierig ausprobiert werden. Hier auch nochmal einen Dank an alle Betroffenen und die Meschen mit Bezug, die uns hier tatkräftig unterstützt haben. Indem sie uns ihr vertrauen schenkten und das bis dahin vorhandene einfach ausprobiert haben, indem sie uns finanziell unterstützten bei Dingen, die wir beide nicht stemmen konnten, indem sie uns Fehlüberlegungen und technisch fehlerhafte Umsetzungen verziehen und Geduld bewiesen, indem sie weiterhin an das Projekt geglaubt haben und uns pausenlos mit Feedback versorgt haben, was aus ihrer Sicht noch fehlt oder so nicht funktioniert. Und nciht zuletzt haben wir von Euch auch das nötige Lob bekommen, um weiterhin mit der nötigen Motivation an dem Projekt weiterzuarbeiten

Aus technischer Sicht wichtig waren Aspekte wie Kommunikationssicherheit und Datenschutz (Ja, Datenschutz ist gerade beim Opferschutz einer der wichtigsten Bestandteile überhaupt, liebe Frau von der Leyen und lieber Herr Schäuble), denn nur in einer geschützen, sicheren Umgebung kann den Menschen das nötige Vertrauen vermittelt werden, das für diese Art Plattform unbedingt und zwingend nötig ist. Hierbei war der Spagat zu bewältigen, einerseits der Administration größtmöglichen Zugriff auf die Identität der Teilnehmer zu gewähren, um Störenfriede erkennen und aussondern zu können, sowie um im nicht gänzlich unwahrscheinlichen Fall, dass sofortige rettende oder helfende Maßnahmen getroffen werden müssen, zeitnah reagieren zu können. Andererseits steht natürlich die Anonymität der Einzelnen ganz oben, und um ernstgenommen zu werden, muss auch alles unternommen werden, dass im Zweifelsfall die Teilnehmer gegen jegliche "feindliche" Auskunftsersuchen geschützt werden können.

Summa summarum haben wir denke ich eine solide Basis geschaffen, dass dieses Projekt (das übrigens auf den klangvollen Namen Farben des Lebens hört) genau das leisten kann, was wir uns erdacht haben. Doch über Erfolg und Misserfolg, das sollte jedem klar sein, der so ein Projekt startet, entscheidet natürlich die härteste Jury der Welt, nämlich das Publikum . in diesem Fall die (zukünftigen) Teilnehmer.

UWP machte mich schon vor einiger Zeit in seinem Blog auf LMMS aufmerksam.

Damals testete ich die 0.2x-Version, die damals aktuell war, bzw. ich versuchte es, aber egal welche Tricks ich anwandte, unter meinem Gentoo-System ließ sich das Zeug ums Verrecken nicht durchkompilieren. Jedenfalls gab ich dann entnervt auf und nahm mir vor, das Projekt im Auge zu behalten, um eine spätere (und hoffentlich ausgereiftere) Version nochmal anzugehen.

Jetzt im Weihnachtsurlaub, fast anderthalb Jahre später, erinnerte ich mich an diesen Vorsatz und besorgte mir den Quelltext für die aktuelle Version 0.4.2. Und siehe da, die alten Dependencies sind noch installiert und die neue Version kompiliert ohne auch nur ein einziges Mal zu mucken ordentlich durch. Gentoo hat jetzt zwar auch LMMS im Repository, aber derzeit noch die Version 0.4.0 und maskiert. Da der Releasezyklus von 0.4.0 bis 0.4.2 sehr zügig schien, versprach ich mir von den aktuelleren Quellen größere Reife - das roch mir denn doch (ohne das Changelog genauer begutachtet zu haben) arg nach Bugfix-Releases.

Nunja, der ganze Kram ließ sich dann sogar problemlos starten nach der Installation. Die Soundausgabe war auch fix umgebogen auf die Onboard-Soundkarte, an der das Headset angeschlossen ist, damit ich auch abends daran rumbasteln kann ohne die Kinder aus dem Bett zu dröhnen. Selbst die Billig-Kombination Intel-ICH5-Onboardsound mit ALSA bringt ein ordentliches Klangerlebnis hervor.

Mal sehen, wenn ich Zeit und Lust und/oder Not habe, werde ich das auch mal mit jackd testen, aber momentan sehe ich noch nicht den entsprechenden Schmerz, der mich dazu veranlassen könnte.

Jedenfalls habe ich schon ein bisschen damit herumgespielt und es erinnert mich in Funktion und Bedienbarkeit durchaus an das von Windows bekannte Fruityloops, auch wenn es (noch) nicht so mächtige Plugins hat wie das buntnamige Windows-Programm - ich vermisse z.B. das Text2Speech-Plugin. Dafür gibt es aber recht leicht Abhilfe unter Linux, da LMMS beliebige Samples importieren kann; wie z.B. welche, die man mit festival erzeugt hat.

Weiterhin unterstützt das Programm u.a. VST- und LADSPA-Plugins, kann .flp-Dateien importieren und so manches mehr, was der Akzeptanz bei Umsteigern und Neu-Suchenden zuträglich ist. Was die Entwickler leider immer noch nicht wirklich in den Griff bekommen haben, sind die bereits von UWP erwähnten Besuche von Mr. Fault, Segmentation Fault, mit der Lizenz zum Datenverlust. Von daher empfiehlt es sich, regelmäßig auf den Speichern-Knopf zu klicken, spätestens nach grundlegenderen Änderungen am Projekt.

Erwähnenswert ist vielleicht auch, dass LMMS von Haus aus nur den Export in WAV und OGG unterstützt, soweit ich das sehe. Das ist aber auch nur relevant für Menschen, die auch Windows-Usern ihre Musik (oder das, was sie dafür halten) präsentieren wollen und lame nicht bedienen können. Denn Windows hat nach wie vor Probleme, das freie OGG-Format abzuspielen, wenn man nicht ein wenig Aufwand betreibt und/oder den "richtigen" Player einsetzt. Achja, Sound-Samples, die man in LMMS verwenden will, sollten auch möglichst in OGG vorliegen.

Alles in allem bin ich sehr angetan von dem Projekt und hoffe, dass die Autoren der Software es bald schaffen, die Stabilität in den Griff zu bekommen - es wäre schade drum, wenn das, was man bisher in dem Programm präsentiert bekommt, durch die Stabilitätsprobleme auf der Datenmüllhalde landen würde.

Aufgrund einiger Einschränkungen, die auf dem bisherigen Server aus Sicherheitsgründen nötig wuden, hat es sich als sinnvoller Weg ergeben, das Blog auf den Tuxhilfe-Stammserver umzuziehen.

Ich kann stolz vermelden, dass dieser Umzug ohne größere Probleme vonstatten ging und die Blog-Software wieder ohne Einschränkungen läuft mit allen nützlichen und unnützen Erweiterungen. Falls doch noch jemandem Fehler o.ä. auffallen sollten, bitte ich denjenigen, mir Bescheid zu geben.

Diesen Vortrag hätte ich mir von vorn bis hinten sparen können. Ich erhoffte mir, wie im Beschreibungstext angekündigt und in der Einleitung des Vortrags von Herrn Werner konstatiert wurde, hier ein wenig über Bedingungen, Fallstricke und ähnlich Beachtenswertes aufgeklärt zu werden, wenn man Software unter einer OpenSource-Lizenz veröffentlichen will.

Am Anfang war das auch ganz kurz Thema in der Form, dass darauf eingegangen wurde, wieviel Mut es zu Beginn erfordert, seine in Code gegossenen Verbrechen deröffentlichen Diskussion preiszugeben. Danach jedoch dümpelte der Vortrag so vor sich hin, nervös-hektisch und doch monoton erzählt (und der macht das wirklich öfter? Der ist wirklich - wie von ihm selbst in den Raum gestellt - für Öffentlichkeitsarbeit in Form von Reden und Vorträgen für das Auswärtige Amt zuständig?). Es wurde ein bisschen von der Migration des gesamten Auswärtigen Amtes erzählt, die wohl seit 2003 läuft - interessante und auch lobenswerte Sache, hätte mich als Vortragsthema auch gereizt, um Erfahrungsberichte zu hören, wie mit der (Nicht-)Akzeptanz der Anwender umgegangen wurde, wie und wo Überzeugungsarbeit geleistet wurde usw. usf. Das wurde auch thematisiert, so ist es nicht. Genauso wie die Lobbyarbeit des Auswärtigen Amtes allgemein und seiner Person im Besonderen, was den Standardisierungsprozess zu OOXML bei den OSI-Gremien betrifft, wie sie sich gegen die aufdringlichen Lobbyisten von Microsoft zu Wehr gesetzt haben etc.

Wirklich spannende und gute Arbeit, da gibt es keine Diskussion. Aber das hilft mir leider versammt wenig dabei, wie ich "alles richtig" mache, wenn ich ein Softwareprojekt unter einer OpenSource-Lizenz veröffentlichen will.

Auch die lustigen kleinen Verstrickungen und Widersprüche, die er sich gemeinsam mit dem auch anwesenden Vertreter des BMI besonders in Bezug auf die Publikumsfragen gegönnt hat, haben leider nicht darüber hinwegtäuschen können, dass ich soeben eine Stunde meines Lebens schlichtweg verschwendet habe.

Wie mittlerweile auch heise festgestellt hat, rollt seit März eine anhaltende Backscatter-Welle durchs Netz und macht Mailserver-Betreibern das Leben schwer. Darum geht es mir hier und jetzt aber eigentlich nicht, daher an dieser Stelle lediglich der Hinweis, dass es hier ein hilfreiches HowTo für Postfix gibt, mit dem man sich recht effektiv des Zeuges entledigen kann. Falls ich Zeit und Lust dazu finde, werde ich hier im Blog auch mal ein kleines HowTo posten, wie ich des Problems auf meinem Server Herr geworden bin.

Ganz Themenfremd ist das aber nicht, denn es geht auch jetzt um SPAM und dessen Bekämpfung auf einem Postfix-Server. Diesmal stehen gar lustige Gesellen im Vordergrund, deren Mailserver behaupten, aus nicht erlaubten bzw. möglichen Netzen zu stammen, die zumindest alles andere tun sollten, als von dieser Adresse aus Mails an öffentlcihe Server abzuliefern.

Netterweise stellt IANA.org unter anderem eine Liste bereit zum derzeitigen Verwendungsstatus der IPv4-Adressen. Noch netter ist, dass diese Liste in einem gut maschinenles- und parsebaren Format daherkommt - man muss sich manuell nur um die historisch gewachsenen Sonderfälle wie die Kapriolen im 192.0.0.0/8-Netz kümmern, die aber auch keinen Änderungen unterworfen sind.

Was man damit machen soll und warum überhaupt kümmern? Wenn z.B. auf dem externen Interface ein Server eine Mail einliefern will, der meint, eine IP-Adresse wie 10.0.8.15, 192.168.42.23 oder 169.254.47.11 als Absende-Adresse kommunizieren zu können, dann will jemand entweder was böses tun, oder aber der Server ist bestenfalls hoffnungslos falsch konfiguriert. Der Unterschied ist unerheblich, da man in beiden Fällen von diesem Server keine Mails haben möchte. Genauso verhält es sich mit Netzen, die nicht vergeben sind oder als Multicast-Netze dienen. Diese Stati kann man alle hervorragend aus der o.g. Liste von IANA herausfinden, in eine Datei packen, die von Postfix (mutmasslich auch von anderen Mailserver-Programmen) verwertet werden kann, um die entsprechenden Server mit solchen komischen Angaben gleich auf SMTP-Ebene abzuweisen.

Da es lästig ist, immer wieder die Liste aufzurufen und auf Änderungen gegenüber der im Mailserver verwendeten Liste zu prüfen, ist es dank der weiter oben erwähnten, leichten Maschinenlesbarkeit der Liste eine prädestinierte Aufgabe für ein kleines Shell-Script, was regelmäßig die Aufzählung der "verbotenen" Netze auf den aktuellen Stand bringt. Das habe ich umgesetzt und nun liegt hier eine Datei im CIDR-Format mit allen für den direkten Mailversand unzulässigen Netzen bereit, die täglich gegen 1:30 Uhr nachts per Cronjob aus den aktuellen Daten der IANA.org erstellt wird.

Der Aufbau der Datei ist folgendermaßen:
In der ersten Spalte steht das betreffende Netz, also z.B. 192.168.0.0/16, dann folgt die Anweisung, wie Postfix damit zu verfahren hat, wenn der fremde Mailserver vorgibt, aus diesem Netz zu kommen (in dieser Konfiguration ganz RFC-konform ein REJECT = Ablehnen), danach weiterführende Informationen zu der Ablehnung, die im eigenen, sowie - falls dort aktiviert - auch im fremden Mailserverlog auftaucht (für dieses Netz lautet die Meldung "mail server in RFC 1918 private network").

Man unterstellt ja zunächst das Positive: Dem Admin des fremden Mailservers ist ein Fehler in der Konfiguration unterlaufen - und so bekommt er über die Logs die Chance zu erkennen, was nicht stimmt und kann mit der Information das Problem besser lokalisieren.

In Postfix ist diese Datei auch ganz leicht zu integrieren:
Man öffnet die /etc/postfix/main.cf und fügt in die smtpd_*_restrictions (am Besten eignen sich die smtpd_recipient_restrictions) folgende Zeile hinzu:

check_sender_mx_access cidr:/etc/postfix/mx_access.cidr,

(das Komma am ende nicht vergessen, wenn es nicht der letzte Eintrag bei den Restrictions ist)

Die CIDR-Datei muss dann natürlich dort auch vorhanden sein, wenn Postfix sie verwenden soll, also cd /etc/postfix/ && wget http://datenhalde.tuxhilfe.de/mx_access.cidr. Damit Postfix die Konfigurationsänderung auch berücksichtigt, sollte ein reload genügen, sicher geht man aber mit einem beherzten /etc/init.d/postfix restart.

Da der jeweilige Status der Netze kein auf ewig festgeschriebenes Dogma ist, kommt man nicht umhin, wie oben erwähnt, diese Liste immer mal wieder zu aktualisieren. Das kann man bequem per Cron machen. Also crontab -e aufrufen und folgende Zeile hinzufügen:

0 4 * * 0 cd /etc/postfix/ && wget http://datenhalde.tuxhilfe.de/mx_access.cidr && /etc/init.d/postfix reload

Jetzt wird jeden Sonntag morgens um 4:00 Uhr die aktuelle Version der Datei geholt und Postfix veranlasst, seine Konfiguration neu einzulesen. Ich bin mir nicht sicher, ob Letzteres wirklich nötig ist, aber schaden kann es nicht.

Nun ist ja wirklich lange nichts mehr passiert hier. Als Ausrede bringe ich an, dass dafür in meinem Leben umso mehr passiert ist

Seit nunmehr einem knappen Monat befinde ich mich in einem neuen Arbeitsverhältnis, wie der ein oder andere Leser vielleicht schon über andere Kanäle mitbekommen hat. Der neue Job macht eine Menge Spaß. bietet ein angemessenes Gehalt, ist aber auch recht fordernd, sodass ich abends seltener die Lust habe, meinen Senf hier im Blog oder anderswo abzusondern, solange die Abende noch immer recht kurz sind und ich mich in die neue Situation eingewöhne.

Allerdings darf ich mich bei meinem neuen Arbeitgeber durchaus mit interessanten Projekten beschaeftigen, deren Erfahrungen ich hier sicherlich demnächst zum Besten geben werde - wie z.B. ein meiner Meinung nach spannendes Mailserver-Setup mit einigen gar wunderlichen Fußangeln, oder die anstehende Migration von CVS (zu vermutlich SVN), wo unter Garantie auch noch die ein oder andere Überraschung auf mich wartet.

Außerdem stehen demnaechst auch voraussichtlich ein paar Neuerungen an, die TuxHilfe betreffen - da stehen auch ein paar nette Dinge in der Warteschlange. Die müssen sich aber leider auch dem Zeitdiktat beugen und abwarten, bis sie an der Reihe sind.

So, das soll erstmal genug Lebenszeichen gewesen sein, in naher Zukunft wird sich wieder ein bisschen was bewegen, hier.

Dass ich mit einem Kumpel zusammen einen kleinen VServer angemietet habe, nahm ich zum Anlass, das längst überfällige Projekt in Angriff zu nehmen, meinen Mailserver komplett neu aufzusetzen. Eine Ausweichbüchse war ja somit vorhanden.

Gesagt, getan. Fix mal einen provisorischen Postfix auf dem neuen Schächtelchen aufgesetzt, einen neuen MX-Eintrag für meine Maildomains hinzugefügt und ran an den Speck.

Soweit lief das auch ganz gut. Nach einem kleinen Auffrisch-Kurs, was meine Postfix-Kenntnisse in Bezug auf Virtualisierung und die entsprechende Abbildung auf eine Datenbank betrifft, war die Geschichte eine schöne Fingerübung. Dann muss natürlich noch der Courier-IMAPd rauf, damit man auch an die Mails rankommt, die da so eintrudeln, und Squirrelmail darf auch nicht fehlen - wie soll ich denn sonst von unterwegs an meine Mails kommen? Ausserdem ist die Frau des Hauses auch glücklicher damit, sich einfach auf einer Webseite einzuloggen um ihre Mails zu lesen, anstatt sich mit einem lokalen Mailclient herumzuschlagen.

Hey, eigentlich eine gute Gelegenheit, den obligatorischen Apache ordentlich herzurichten und das Zeug über HTTPs laufen zu lassen. Sprach es und arbeitete sich flugs ein bisschen in die Untiefen von OpenSSL ein, und darin, wie man eine eigene Certificate Authority (CA) einrichtet und verwaltet. So soll endlich nach Außen hin eine konsistente Struktur in die ganze Geschichte gebracht werden. Wirkt einfach besser. Kommt mir auch zugute, da sich mein neuer zukünftiger Arbeitgeber sicher auch ein wenig die Dinge anschauen wird, die ich bisher so verbrochen habe - und gerade die Sache mit der Nutzung von SSL-Zertifikaten lag ihm auch am Herzen.

Also gut, eine eigene CA aufgebaut, schnell die Keys und Zertifikate für die Apache-Vhosts erzeugt und gegensigniert, lief alles top - und wo man grad so schön dabei ist, kann man doch gleich mal Postfix ein paar ordentliche Zertifikate spendieren und bei der Gelegenheit auch der SSL-Version vom Courier-IMAPd ein in die TuxHilfe.de-Welt gehöriges Cert unterschieben. OK, Postfix hätte seinen Serverkey gern bitteschön ohne schützende Passphrase, da er es im Gegensatz zu Apache2 nicht schafft, beim Neustart des Dienstes auf der Konsole eine kleine Abfrage zu präsentieren. Kein Problem, machen wir - passende Rechte setzen nicht vergessen, schließlich soll zwar Postfix, aber nicht die halbe Welt den privaten Schüssel lesen dürfen - er ist ja eben privat und nicht öffentlich.

Da der IMAPs-Dämon über denselben Hostnamen anzusprechen ist, kann man ihm doch gleich dasselbe Zertifikat wie Postfix unterjubeln... dachte es und packte sich erstmal der Länge nach auf die Nase:

error:0906D06C:PEM routines:PEM_read_bio:no start line

prangte es mir aus den Logs entgegen und sah nicht ein, mich an meine Mails zu lassen. Was zur Hölle?!

Einmal head -n 1 bitte für alle Schlüssel!

-----BEGIN RSA PRIVATE KEY-----

war die einhellige Antwort, die mir entgegenschallte - sowohl bei dem von mir erzeugten, als auch bei dem funktionierenden, generischen Schlüssel, den das Paket bei der Installation spontan erzeugt hatte. Das brachte mich so nicht weiter, also ließ ich mir weitere Details ausspucken.

Und siehe da! Die automatisch generierte, sich selbst signierende Schlüsseldatei beinhaltete sowohl den privaten Schlüssel, als auch das zugehörige signierte Zertifikat nebst Diffie-Hellman-Parameter. Was für ein Sch**ß!

Nunja, alles Fluchen hilft nix, davon löst sich auch kein Problem. Durch Bemühen des Befehls cat (der ja immer wieder mit Freuden unnützerweise genutzt wird -> 'useless use of cat') beförderte ich also den Inhalt der Zertifikats- und der Schlüsseldatei in ein und denselben Dateisystem-Eintrag, welchen ich Courier mitteilte, sodass er ihn fürderhin nutzen möge. Dieser nahm die Information dankbar entgegen und belohnte mich mit dem uneingeschränkten Zugriff auf meine elektronische Post.

Wenn mir jemand einen Rat geben kann, wie ich Courier davon überzeuge, dass Schlüssel und Zertifikat nicht in dieselbe Datei gehören, dann bitte ich ihn, mir diesen zukommen zu lassen.