Category Archives: Uncategorized

HowTo: CAcert Zertifikat für eisfair-Webserver

Der Apache-Webserver für eisfair kann selbstverständlich auch mit SSL umgehen. Das ist beispielsweise sinnvoll für alle Anwendungen, die man auf dem heimischen Server laufen lassen möchte und die Authentifizierung verlangen, damit die Passwörter, die über’s Netz gehen definitiv verschlüsselt sind. Auch die Inhalte wie beispielsweise die vom Webmailer bleiben der Öffentlichkeit lieber verborgen.

Wenn man bei CAcert angemeldet ist, liegt es nahe, sich auch für den eisfair-Server zu Haus ein passendes Zertifikat ausstellen zu lassen. Voraussetzung dafür ist folgendes:

  • eisfair-Server mit den installierten Paketen apache2 und certs
  • Account bei CAcert und genügend Punkte zum Erstellen eigener Server-Zertifikate

Sind alle Voraussetzungen erfüllt, geht man wie folgt vor. Zunächst ruft man auf dem eisfair-Server das Setup-Menü auf und geht ins Service-Menü von certs. Dort wählt man den Punkt Manage certificates. Daraufhin ändert man über 1 den key type auf web server. Als nächstes wählt man Punkt 10 (create a new key or select an exiting one [apache]), sonst schlägt der folgende Punkt fehl. Nun wählt man Punkt 11 (create certificate request), das verlangt CAcert nämlich später beim Erstellen des Zertifikats. Bei den Eingaben kann man sich weitestgehend an die Vorgaben halten. Wichtig: Als Common Name die Domain (FQDN) angeben, unter der der Server später erreichbar sein soll, beispielsweise www.example.dyndns.org, wenn man das später von draußen so im Browser eintippt, um den Heimserver zu erreichen. Als Challenge passwort gibt man einen einfachen Punkt ein.

Der Certification Request liegt jetzt unter /var/certs/ssl/csr/apache.csr. Den Inhalt dieser Datei benötigt man, um nun auf der Webseite von CAcert sein Zertifikat zu beantragen. Also kopiert man den Inhalt der Datei und loggt sich bei CAcert ein. Dort wählt man auf der rechten Seite Server Zertifikate und Neu. Nach einem langen, wichtigen Text gibt es unten ein großes Eingabefeld, in das man nun den Inhalt der Zwischenablage beziehungsweise den Certification Request einfügt. Anschließend auf Abschicken klicken, nochmal den Common Name gegenprüfen und nochmal Abschicken klicken.

Daraufhin zeigt die CAcert-Webseite das neue Zertifikat an. Das kopiert man und speichert es auf dem eisfair-Server in eine Datei mit der Endung .pem, beispielsweise www_example_dyndns_org.pem. Diese Datei kopiert man nun mit root-Rechten nach /var/certs/ssl/certs/. Anschließend ruft man ebenfalls mit root-Rechten einmal das Skript /usr/bin/ssl/c_rehash auf.

Mit einem aktuellen apache2 (probiert mit 1.3.4) wird man bei Aktivierung der Option APACHE2_SSL in der Konfiguration beim ersten Aktivieren einmal durch die komplette Zertifikat-Erstellungsprozedur geschickt, die genutzt wird, wenn der eisfair-Server selbst eigene Zertifikate ausstellt. Da wurstelt man sich einmal durch. Anschließend muss man dem Apache aber noch das CAcert-Zertifikat unterschieben. Wenn vHosts verwendet werden, gibt man den oben vergebenen Dateinamen einfach ohne Endung in der Variablen APACHE2_VHOST_?_SSL_CERT_NAME an. Verwendet man keine vHosts ist noch etwas Trickserei erforderlich. Der Apache erwartet das Zertifikat dann in /usr/local/ssl/certs/apache.pem bzw. (da /usr/local/ssl nur noch ein Symlink auf /var/certs/ssl ist) /var/certs/ssl/certs/apache.pem.

Jetzt gibt’s mehrere Möglichkeiten: apache.pem mit der neuen Datei überschreiben, einen symbolischen Link mit dem Namen apache.pem auf die neue Datei setzen oder den entsprechenden Teil aus der neuen Datei im Editor kopieren und in apache.pem ersetzen. Die zweite Variante (root-Rechte):

cd /var/certs/ssl/
mv apache.pem apache.pem.bak
ln -s www_example_dyndns_org.pem apache.pem
/usr/bin/ssl/c_rehash

Anschließend den Webserver nochmal neu starten, fertig. Der Apache ist fortan über https://www.example.dyndns.org mit einem von CAcert signierten Zertifikat erreichbar.

IT-Projekte 2009

Das Jahr ist zwar schon etwas fortgeschritten, trotzdem habe ich mir vorgenommen, bis zum Ende des Jahres in meiner Freizeit ein paar IT-Projekte voranzubringen. Aus der doch recht großen Auswahl der Projekte, die mich interessieren, habe ich die folgenden herausgepickt:

  1. IMPULS: Dieses Projekt hat inzwischen doch schon ein paar Jahre hinter sich und es gab diverse Situationen, in denen ich es gebraucht hätte. Bis Ende des Jahres sollten hier ein lauffähiger Daemon (aber auf Java-Basis) und ein paar Clients sowie mindestens ein Reader stehen.
  2. Antiblau: Den Server haben wir seit Ende 2005, aber noch immer sind ein paar Funktionen nicht verfügbar und auch die vorhandene Administrations-Infrastruktur kann mal modernisiert werden.
  3. Debian: Entwickler werde ich wohl in diesem Jahr nicht, aber ein paar Pakete aus eigenen Sachen möchte ich bauen und wenigstens soweit in die Community reinschauen, dass ich sicher entscheiden kann, ob ich überhaupt Entwickler werden will.
  4. QCaff: Eine grafische (Qt-basierte) Variante von CAFF, die sowohl unter Windows als auch unter Linux laufen soll und das Management von GPG-Keys für Jedermann ermöglichen soll. Insbesondere bei der Nachbereitung von Keysigning-Parties besteht hier offenbar Softwarebedarf. Wenn alles klappt, ist das aber trotzdem ein recht überschaubares Tool. Sofern vorhanden, werde ich bestehende Lösungen weiterverwenden.

Weiterhin warten auch bei UniMentor interessante Programmieraufgaben und der FaRaFIN kann ebenfalls mit einem interessanten Projekt aufwarten. Anfang 2010 werden wir sehen, was davon ich umsetzen konnte.

Debian und ausgelagerte Firmware in Linux 2.6.29

Mein Notebook arbeitet wie so viele andere mit einem Chipsatz von Intel, d.h. LAN und WLAN läuft beides mit Intel Chips:

lassy:~# lspci | grep 'Network|Ethernet'
02:07.0 Network controller: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection (rev 05)
02:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VE (MOB) Ethernet Controller (rev 81)

Nun kam heute früh der neue Linux Kernel 2.6.29 in Debian unstable an. Bei der Installation wunderte ich mich schon, dass das Update der initramfs nicht 100% glatt lief und folgende Meldungen kamen:

W: Possible missing firmware /lib/firmware/e100/d102e_ucode.bin for module e100
W: Possible missing firmware /lib/firmware/e100/d101s_ucode.bin for module e100
W: Possible missing firmware /lib/firmware/e100/d101m_ucode.bin for module e100

Beheben ließ sich das in meiner Debian-Installation dann einfach durch die Installation der Pakete firmware-ipw2x00 und firmware-linux.

Speicherlimits von MiKTeX erhöhen

Vor einiger Zeit hatte ich im Beitrag Schicke Grafiken in LaTeX mit pgfplots (1) eine elegante Möglichkeit vorgestellt, größere externe Datenmengen in schicke LaTeX-Plots zu verwandeln. Ich mache das immer noch sehr ähnlich, bin aber heute auf ein Problem gestoßen, das auch in der Dokumentation zu pgfplots Erwähnung findet. Im Kapitel »7 Memory and Speed considerations« heißt es dort:

The default settings of most TEX-distributions are quite restrictive, so it may be necessary to adjust them.

Dieses Limit hatte ich nun offenbar auf meinem Notebook erreicht. Die Doku zu pgfplots schlägt vor, die Limits mit Kommandozeilenparametern beim Aufruf von pdflatex zu erhöhen. Das funktionierte in meinem Fall leider nicht, da ich gleichzeitig auch noch die Funktionalität von pgf/pgfplots zum Wiederverwenden bereits kompilierter Grafiken einsetze, Stichwort externalize. Dort wird aus pdflatex heraus noch ein weiterer Lauf von pdflatex gestartet. Jetzt hätte ich diesen Aufruf anpassen und mit dem entsprechenden Parameter versehen können, aber dann wäre ich unter Linux auf die Nase gefallen, wo ich das Dokument ebenfalls kompilieren will.

Im Hinterkopf aus meinen ersten Experimenten mit pgfplots hatte ich aber, dass man diese Memory Limits auch irgendwo global setzen kann. In einem alten Thread in de.comp.text.tex hatte ich schon fast die richtige Lösung gefunden, aber der Tipp initexmf --edit-config-file=latex auf der Kommandozeile und dann im Editor den Wert anpassen funktionierte nicht.

Auf die richtige Spur kam ich dann als ich in C:\Programme\MiKTeX 2.7 eine Suche in den Dateien nach dem alten Limit ausführte. Ich erwartete eigentlich eine Konfigurationsdatei zu finden, aber ich wurde mit der Nase auf die Dokumentation von MiKTeX selbst gestoßen: C:\Programme\MiKTeX\2.7\doc\miktex\miktex.pdf. Da steht in Abschnitt »5.4 Changing TEXMF run-time parameters« nämlich genau, was zu tun ist:

initexmf --edit-config-file=pdflatex

Man beachte den kleinen Unterschied zu oben. ;-)
In der Datei hab ich dann jedenfalls folgendes eingetragen:

main_memory=3000000

Jetzt kompiliert mein Dokument wieder, ich kann fröhlich weiter arbeiten und schreibe mir selbst nochmal ein dreifaches RTFM hinter die Ohren.

Scrollbalken im Midnight Commander

Ein interessantes, wenn auch eher unwichtiges Problem kam kürzlich in einem Chat des fli4l/eisfair-Teams auf. Der Entwicklungsserver wurde umgebaut und das System neu aufgesetzt. Mit dem Upgrade auf Debian Lenny hielt auch UTF-8 Einzug und sorgte natürlich für allgemeine Verwirrung. Viele Nutzer arbeiten mit PuTTY auf der Maschine. Dort muss man nicht nur das Locale des Servers richtig einstellen, sondern auch die Line Drawing Character auf Unicode stellen und eine passende Schrift auswählen. Dass dies nicht so einfach ist, habe ich letztens erst ausführlich beschrieben.

Im konkreten Fall hatte einer der Entwickler PuTTY korrekt eingerichtet und als Schrift die Courier New ausgewählt. Das Problem: der Midnight Commander stellt alles korrekt dar, bis auf die Scrollbalken, wo nur hässliche Kästchen erscheinen. Das Problem ließ sich relativ leicht verifizieren. Auf einem Debian Lenny, sieht das mit Courier New tatsächlich so aus, bei einer Verbindung zu einem Debian Etch sieht man mit Courier New hingegen korrekt dargestellte Pfeile. Ein Umschalten auf die von mir bevorzugte DejaVu Sans Mono bewirkte in beiden Sessions eine korrekte Darstellung. Wenn man genau hinsah, zeigten sich aber subtile Unterschiede.

Ich hab dann die entsprechenden Zeichen kopiert und im Hex-Editor unter die Lupe genommen. Auf dem Rechner mit Etch gab ein `mc --version` (gekürzt) folgendes:

GNU Midnight Commander 4.6.1

Mit dem Wissen aus meinem früheren Beitrag »Wie funktioniert UTF-8?« sah meine Analyse der Zeichen dann so aus:

▲ – E296B2h – 11100010 10010110 10110010 – 00010010110110010b – 9650 – U+25B2
● – E2978Fh – 11100010 10010111 10001111 – 00010010111001111b – 9679 – U+25CF
▒ – E29692h – 11100010 10010110 10010010 – 00010010110010010b – 9618 – U+2592
▒ – E29692h – 11100010 10010110 10010010 – 00010010110010010b – 9618 – U+2592
▼ – E296BCh – 11100010 10010110 10111100 – 00010010110111100b – 9660 – U+25BC

In den letzten beiden Spalten stehen die Unicode-Nummern der Zeichen in dezimal und hexadezimal. Auf decodeunicode.org findet man raus, dass diese alle zur Gruppe »Geometric Shapes« gehören und korrekt encodiert sind. Diese Zeichen werden mit Courier New wie bereits erwähnt korrekt dargestellt. Bei Lenny gibt es eine neuere Version des Midnight Commander:

GNU Midnight Commander 4.6.2-pre1

Bei dieser Version sehen die Scrollbalken dann so aus:

▴ – E296B4h – 11100010 10010110 10110100 – 00010010110110100b – 9652 – U+25B4
◈ – E29788h – 11100010 10010111 10001000 – 00010010111001000b – 9672 – U+25C8
▒ – E29692h – 11100010 10010110 10010010 – 00010010110010010b – 9618 – U+2592
▒ – E29692h – 11100010 10010110 10010010 – 00010010110010010b – 9618 – U+2592
▾ – E296BEh – 11100010 10010110 10111110 – 00010010110111110b – 9662 – U+25BE

Auch diese Zeichen gehören zur Unicode-Untergruppe »Geometric Shapes« und sind absolut korrekt encodiert, aber sie sind leider nicht in Courier New enthalten. Davon kann man sich unter Windows XP überzeugen, indem man im Startmenü unter Zubehör und Systemprogramme die Zeichentabelle öffnet. Als Schriftart dann Courier New wählen, erweiterte Ansicht auswählen, als Zeichensatz Unicode, Gruppieren nach Unicode-Unterbereich und dort dann Block-/geometr. Elemente. Die dicken Pfeile vom mc 4.6.1 sind drin, die kleineren nicht.

Diese unscheinbare Änderung lässt sich tatsächlich auf den Midnight Commander zurückführen. Wenn man sich mal den UTF-8 Patch im Downloadbereich auf midnight-commander.org ansieht, dann findet man an entsprechender Stelle im Quellcode genau diese Zeichen.

Simple Lösung: eine andere Schrift als Courier New auswählen. Das gilt übrigens auch für den Browser, falls in obigem Beispiel anstelle der Pfeile auch nur komische Zeichen zu sehen sind. ;-)

eisfair-HowTo: richtig krasse Spam-Mails automatisch löschen

Spam, Spam, Spam, Spam und das jeden Tag. Mein Setup sieht derzeit so aus, dass auf meinem eisfair-Server das Paket mail installiert ist. Dies sammelt via fetchmail die Mails von meinen Mailkonten ein, jagt die durch ClamAV und durch SpamAssassin und verteilt die dann wahlweise auf mein IMAP-Konto oder zum User spam. Das funktioniert sehr gut, auch die false positive Rate des Spam-Filters ist traumhaft, ich kann mich an keinen einzigen in den letzten drei Jahren erinnern.

Nichtsdestotrotz kommen immernoch zu viele Spam-Mails durch. Peter vom Fli4l-Team wurde das bei derselben Software zu viel und kam im IRC mit folgender Lösung um die Ecke: alle Spam-Mails, die von SpamAssassin einen Score größer als 10 bekommen, werden direkt nach /dev/null verschoben, also unwiderruflich gelöscht. Als ich gestern die aktuelle Welle in meinem Spam-Ordner anrollen sah, hab ich beschlossen, das auch umzusetzen.

Mit eisfair ist das zum Glück spielend leicht. Man erstellt als root einfach eine Datei namens custom-systemfilter.rm_spam_mail im Ordner /var/spool/exim und übergibt die dann mit

chown exim:trusted /var/spool/exim/custom-systemfilter.rm_spam_mail

dem passenden Systemnutzer. Der Inhalt muss wie folgt aussehen:

# Exim custom filter
#------------------------------------------------------------------------------
if $h_X-Spam-Score: contains "++++++++++++"
then
    logfile /tmp/exim_filter_rm_spam.log
    logwrite "$tod_log To=$h_to Subject=$h_subject From=$h_from Id=$message_id"
    save /dev/null
endif

(Bei neueren Versionen des Pakets mail kann man die Datei direkt aus /usr/local/exim/examples kopieren.)

Dann geht man ins Setup-Menü, dort in die Konfiguration vom Paket mail und lässt die einmal neu durchlaufen. Das Paket erkennt die zuvor erstellte Datei und meldet folgendes:

adding custom system filter /var/spool/exim/custom-systemfilter.rm_spam_mail ...

Fertig, naja fast. Wer den Filter aufmerksam angesehen hat, erkennt, dass das Log erstmal provisorisch in /tmp/exim_filter_rm_spam.log landet. Eleganter ist es, das Logfile dahin schreiben zu lassen, wo die anderen Logfiles von exim landen, nämlich nach /var/spool/exim/log. Dazu ändert man den Pfad im obigen Beispiel entsprechend ab. Jetzt fehlt noch das logrotate dafür. Dazu kopiert man am besten /etc/logrotate.d/mail in eine neue Datei, beispielsweise /etc/logrotate.de/exim_filter_rm_spam. Diese Datei passt man nun an seine Bedürfnisse an, d.h. man schmeißt den Abschnitt für fetchmail raus, ändert die Pfadangabe für das Logfile und spielt dann noch bisschen mit den eigentlichen Einstellungen. Bei mir sieht das Ergebnis so aus:

#------------------------------------------------------------------
# Creation: 2009-07-07 alex
#------------------------------------------------------------------
/var/spool/exim/log/exim_filter_rm_spam.log {
    rotate 53
    weekly
#    compress
    missingok
    notifempty
    sharedscripts
    create 640 exim trusted
    postrotate
        /etc/init.d/mail -quiet reload exim
    endscript
}

Ich lasse in dem Fall recht viele wöchentliche Logfiles übrig und lasse die nicht komprimieren. Das ermöglicht eine einfache statistische Auswertung, wieviel Spam tatsächlich gelöscht wurde (auch wenn ich das noch nicht umgesetzt habe).

Mehr Infos über das eisfair-Paket gibt’s in der eisfair-Dokumentation im Abschnitt Mail-Package. Die Filter vom Mailserver Exim sind detailliert auf exim.org beschrieben.

Ach und wer erkannt hat, dass ich in meinem Filter die Mails erst ab einen Score von 12 wegwerfe und nicht wie Peter schon bei 10, bekommt ein Bienchen!

HTML-Entities mit WP-Syntax 0.9.2

Für die Darstellung von Code-Schnipseln, speziell das Syntax-Highlighting setzen wir das Plugin WP-Syntax ein. Probleme gab es bisher immer mit Code, der die speziellen HTML-Entities enthielt, also hauptsächlich die öffnenden und schließenden spitzen Klammern, die in der einen oder anderen Sprache irgendwie als Vergleichsoperatoren eingesetzt werden: < und >.

Bisher bin ich Problemen damit so aus dem Weg gegangen, dass ich entsprechende Zeichen im Beitragseditor durch &lt; und &gt; ersetzt hatte. Damit das Plugin damit umgehen konnte, war bei jedem Update eine kleine Änderung notwendig, für Version 0.9.1 sah der Patch beispielsweise so aus:

--- wp-syntax.php  2008-08-24 19:22:12.000000000 +0200
+++ wp-syntax.php  2008-08-25 15:26:48.000000000 +0200
@@ -97,7 +97,8 @@
     $line = trim($match[2]);
     $code = wp_syntax_code_trim($match[3]);

-    $geshi = new GeSHi($code, $language);
+    $geshi = new GeSHi(htmlspecialchars_decode($code), $language);
     $geshi->enable_keyword_links(false);
     do_action_ref_array('wp_syntax_init_geshi', array(&$geshi));

Ab WP-Syntax 0.9.2 ist das nicht mehr notwendig. Die Release Notes sagen ganz lapidar:

**0.9.2** : Updated to use GeSHi v1.0.8.2; Added optional `escaped=”true”` support in case code snippets are already escaped with html entities.

In der Praxis sieht das dann so aus:

    <pre lang="xml" escaped="true">
    &lt;xml&gt;Hello&lt;/xml&gt;
    </pre>

Das vereinfacht zukünftige Upgrades von dem Plugin, ist also eine feine Sache. Für vergangene Beiträge musste ich jetzt allerdings nochmal von Hand diesen Parameter setzen. Wenn mir da irgendwo was durch die Lappen gegangen sein sollte, einfach mal kurz anpiepsen, dann behebe ich das.

GRUB Error 2

Manchmal findet man seltsame Sachen heraus. Wusste hier jemand, dass nicht alle Versionen von GRUB alle Versionen von ext3 lesen können? Ok, klingt erstmal logisch, dass das für ziemlich alte Versionen von GRUB und für ziemlich neue Versionen von ext3 gilt. Gut da fragt man sich erstmal, wie es denn überhaupt Versionen bei ext3 geben kann, aber egal, vielleicht fang ich die Geschichte doch besser vorn an.

Letze Woche hat sich eine meiner alten Festplatten verabschiedet, wo zu Testzwecken ein Debian Sid installiert war. Gestern bekam ich von Tux Ersatz und heut dachte ich mir, schiebst Du »mal eben kurz« wieder das System drauf. Die Installation verlief auch zügig und glatt. Den Bootloader ließ ich in den MBR von /dev/hdc schreiben und laden wollte ich das ganze wie üblich, nämlich über folgenden Eintrag im GRUB von /dev/hda (das zu nem Ubuntu gehört):

title       hdc: Debian Sid
configfile  (hd2,0)/boot/grub/menu.lst

Das funktioniert üblicherweise wunderbar. Man gelangt zunächst in das Bootmenü vom GRUB auf /dev/hda und von dort über obigen Eintrag in das Menü von /dev/hdc. So können die Systeme auf jeder der Platten ihre eigenen Bootloader eigenständig verwalten und kommen sich auch bei Kernelupdates nicht ins Gehege. Heute führte das allerdings zum Error 2. Das Handbuch von GRUB sagt dazu lapidar:

2 : Bad file or directory type
This error is returned if a file requested is not a regular file, but something like a symbolic link, directory, or FIFO.

Die Recherche nach der Lösung zu solchen Fehlern gestaltet sich natürlich schwierig. Ich hatte ein wenig Glück und fand diesen Thread im Ubuntu-Forum. Dort näherte man sich Stück für Stück einem ähnlichen Problem. Ich konnte ebenfalls mit der GRUB-Shell verifizieren, dass das GRUB aus dem MBR meiner /dev/hda nicht in der Lage war das Filesystem auf /dev/hdc1 zu lesen, obwohl letzteres ein sauberes (fsck von GRML drüberlaufenlassen) ext3 war. Mit anderen ext3 kam das bis dahin ja auch klar. Recht weit unten in dem Thread schreibt dann jemand:

Did you upgrade to Hardy from an earlier version of Ubuntu? Then you might of have older version of grub which cannot read ext3 partition with 256 inodes.

Da hab ich nicht schlecht geschaut. Das heißt einerseits wie eingangs angedeutet, dass es vorher (dieses mysteriöse »früher«) ext3 nur mit weniger inodes gab und ältere Versionen von GRUB mit so vielen nicht umgehen können. Das GRUB ist tatsächlich ein wenig älter, das Ubuntu ist ungefähr 2005 auf die Kiste gekommen, also wahrscheinlich ursprünglich als Dapper Drake oder vielleicht sogar noch Breezy Badger. Na und der aktuelle Installer von Debian Lenny scheint derart neue ext3-Formatierungen zu schreiben. Einfaches Neuschreiben des Bootloaders mit dem aktuellen GRUB von Intrepid Ibex hat dann jedenfalls im Handumdrehen das Problem behoben. Ich sag ja, seltsame Sachen gibt’s.

Erinnerung an unser Gewinnspiel

Wer dachte, dass es sich im Artikel Gewinnspiel zum Jahreswechsel, den ich am 11.11. veröffentlichte, um einen Faschingsscherz handelte, liegt falsch. Wir verlosen tatsächlich ein Shirt, und zwar unter allen, die unsere drei Fragen dazu richtig beantworten können. Klickt einfach oben auf »win!« oder hier um alle Einzelheiten zu lesen.

Ganz nebenbei sei erwähnt, dass mit dem heutigen Tag die Anzahl der notwendigen richtigen Einsendungen, um die eigentliche Verlosung zu starten, von 23 auf 19 gesenkt wurde!

Vorsicht Kunde!

Ich bin ein Freund freier Software und ich verwende diese sehr gern auf alten Rechnern. Das ökologische Bewusstsein lässt mich vom Kauf neuer Hardware stets zurückschrecken, wenn die alte noch funktioniert. In einem dieser Rechner ist (bis auf den im Notebook) mein einziger DVD-Brenner eingebaut, ein mittlerweile etwas älteres Teil von LG (GSA-4163A), das auch DVD-RAM brennen kann. Auf dem Rechner ist »nur« Debian installiert und das Brennen mit k3b funktioniert tadellos.

Nun hatte ich letzte Woche nach längerer Zeit mal wieder neue DVD-Rohlinge gekauft, weil mir die alten ausgegangen waren. Ich dachte, es könne nicht schaden, mal nach neuer Firmware für den DVD-Brenner zu schauen, die Hersteller optimieren ja doch die Brennrezepte und packen das in neue Firmware.

Leider war es mir mit Firefox/Iceweasel auf dem Debian nicht möglich auf der Webseite von LG die entsprechende Firmware zu finden. Auf dem Windows-Notebook mit Firefox und Opera sah das dann genauso aus, also machte ich meinem Ärger beim Kundenservice Luft:

Sehr geehrte Damen und Herren,

mir ist es leider mit drei verschiedenen Browser nicht gelungen eine aktuelle Firmware für meinen DVD-Brenner von Ihrer Website zu laden. Entweder wurde überhaupt keine Suchfunktion angezeigt oder es wurden keine Ergebnisse gefunden. Einfache Listen ohne Javascript und Flash, wo man schnell und einfach findet was man sucht, wären wesentlich kundenfreundlicher. :-(

Mit freundlichem Gruß
Alexander Dahl

Im Anschluss daran fand ich noch die »richtige« Supportseite und die aktuelle Firmware. Das hätte mich allerdings keinen Schritt weiter gebracht, denn dort heißt es:

1.verbinden Sie das Laufwerk als Master mit dem secondary IDE-Controller
setzen Sie den Jumper auf der Rückseite des Laufwerkes auf Master. Verbinden
Sie kein anderes Gerät an diesem IDE-Kabel.

Abgesehen von dieser widersinnigen Bastelei hätte mir aber noch etwas anderes einen Strich durch die Rechnung gemacht:

Diese Firmware ist nur für den Gebrauch an PC`s mit den Betriebssystemen:
Windows XP, Windows 2000, Windows Millennium Edition (ME), und
Windows 98SE.

Das ist so natürlich Unsinn. Richtig ist, dass die Software zum Firmware-Upgrade nur unter den oben genannten Betriebssystemen läuft. Alle anderen sind außen vor. Glücklicherweise ist die »neueste« Firmware für das Gerät schon älter. Ein kurzer Check verriet mir, dass diese bereits installiert war.

Damit hätte die Geschichte abgeschlossen sein können, das war wie gesagt alles letzte Woche. Der Kracher kommt aber noch, nämlich die Antwort auf meine Anfrage beim Support:

Sehr geehrter Herr Dahl,

herzlichen Dank, dass Sie mit LG Electronics Deutschland GmbH Kontakt aufgenommen haben.

Wahrscheinlich benutzen Sie den Browser Mozilla Firefox. Da unsere Seite fuer den Internetexplorer optimiert ist, moechten wir Sie bitten diesen zu verwenden.
Dann haben Sie auch bei der Suchoption den gewuenschten Erfolg.

Bei Rueckfragen senden Sie bitte den gesamten Mailverkehr als Anhang mit.

Wenn Sie noch weitere Fragen oder Anregungen haben sollten, können Sie sich jederzeit wieder an uns wenden.

Mit freundlichen Gruessen

Fragen hätte ich keine, aber eine Anregung an LG: Gestalten Sie doch bitte Ihre Webseiten so, dass nicht nur Nutzer des Internet Explorer alle gewünschten Informationen erhalten und ermöglichen Sie Nutzern freier Betriebssysteme auch ein Firmware-Upgrade, zur Not über irgendeine Bootdiskette oder -CD!

Nachtrag: Ich dachte mir, dass LG das hier wohl nicht lesen würde, also antwortete ich per Mail:

Sehr geehrte Damen und Herren,

Sie boten in der Antwort auf meine Anfrage an, mich mit weiteren
Anregungen an Sie zu wenden – gern.

Ich würde es zunächst begrüßen, wenn Sie Ihre Webseiten nicht nur auf
einen einzigen Browser optimieren würden, sondern der wachsenden Zahl
von Nutzern alternativer Browser und Betriebssysteme ebenso ermöglichen,
an die gewünschten Informationen zu gelangen.

Desweiteren empfinde ich es als klare Einschränkung, Firmware-Upgrades
nur unter den teuren Betriebssystemen von Microsoft durchführen zu
können. Nutzer von Linux, BSD oder Solaris sind praktisch nicht in der
Lage Ihre Hardware sinnvoll einzusetzen, weil Ihnen Firmware-Upgrades
verwehrt bleiben. Wie wäre es stattdessen Images für Boot-Disketten oder
-CDs bereitzustellen, von denen das Firmware-Upgrade
betriebssystemunabhängig möglich ist?

Mit freundlichem Gruß
Alexander Dahl

Was kommt zurück?

I’m sorry to have to inform you that your message could not
be delivered to one or more recipients. It’s attached below.

For further assistance, please send mail to

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The Symantec Mail Security program

: host 156.147.51.142[156.147.51.142] said: 550 gsfs@lge.com…
No such user (in reply to RCPT TO command)

Gut, wer nicht will, der hat schon – dann halt nicht.