Qbi's Weblog

Eine E-Mail von GMX Internet Services GmbH befand sich heute in meiner Inbox. Darin wurde ich aufgefordert, mein Konto zu aktualisieren:

Der Verweis zeigt auf eine korrekte Seite bei GMX. Wenn man sich die Header der E-Mail anschaut, stellt man fest, dass zwischen diversen Servern mit der Domain kundenserver.de unterwegs war. Da kommt die Frage auf, warum sollte GMX denn die Infrastruktur von 1&1 nutzen? Wenn ich nicht falsch liegen, sind die kundenserver.de-Adressen eher Root- bzw. V-Server. Auch wenn GMX und 1&1 Tochterunternehmen sind, so klingt das doch recht unwahrscheinlich. Ein paar Zeilen weiter unten fand sich dann der Eintrag:

Received: from 198.54.202.246 (IP may be forged by CGI script)
        by icpu540.kundenserver.de with HTTP
        id 4Ag4pp-1OmMzv2YAm-0006An; Fri, 20 Aug 2010 10:30:47 +0200

Den letzten Hinweis, dass diese E-Mail Phishing ist, lieferte ein Blick in den Quellcode der HTML-Mail. Der Link, der in meiner Mailansicht noch so unschuldig auf GMX zeigte, zeigte in Wirklichkeit auf eine Seite, die vom Firefox als Phishing klassifiziert ist.

Vor nicht allzu langer Zeit sass ich entspannt bei einem Kaffee und wollte meinen Rechner starten. Einschaltknopf gedrückt und der Bildschirm lächelte mich mit einer Fehlermeldung an:

error: unexpectedly disconnected from boot status daemon
Begin: Waiting for root file system ...

grml, warum muss das ausgerechnet jetzt passieren? Sehr schnell war klar, dass ich an dieser Stelle nicht weiter komme. Also bootete ich einen alten, funktionierenden Kernel und änderte meine grub-Einstellungen entsprechend. Damit lebte ich einige Zeit gut, bis mir mal wieder der Workaround auffiel. Jetzt wollte ich das Problem mal genauer angehen.

Die Fehlermeldung, die irgendwas von dem Boot Status Daemon erzählte, schien auf plymouth hinzudeuten. Der Sinn der Software ist es, den Bootprozess zu verschönern. Das heißt, es macht schicke Bildchen anstatt der Kernelmeldungen.

Der Bugtracker von Debian hatte einen Eintrag zu meiner Meldung. Die in dem Bugreport genannten Einstellungen änderten bei mir nichts am Problem. In meinem nächstem Versuch wollte ich plymouth deinstallieren. Aber da gab es eine winzige Abhängigkeit zu mountall(8). Der Zufall führte mich zu einem angepasstem Paket, mit dem plymouth deinstalliert werden kann. In freudiger Erwartung startete ich den Rechner neu. Aber es wäre nur zu schön gewesen, wenn sich das Problem so leicht lösen ließe.

Zu diesem Zeitpunkt kam mir in den Sinn, die Bootoptionen quiet und splash zu entfernen. Siehe da, ein wenig mehr kam zum Vorschein:

Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Waiting for root file system ...

Warten, warten und nochmal warten. Oh, nun noch eine BusyBox-Shell:

(initramfs) Gave up waiting for root device. Common problems:
...
ALERT! /dev/disk/by-uuid/.... does not exist. Dropping to a shell!

Nebenbei stellte ich dann fest, dass die Meldung mit dem Boot Status Daemon nur bei einer speziellen Kernelversion auftrat. Die Meldung oben konnte ich mit jeder Standard-Ubuntu-Kernelversion größer als 2.6.32-20 erzeugen. Für mich wäre es viel wichtiger zu erfahren, woher denn diese Meldung stammt!

Ein Hinweis brachte mich dann zu den Mainline-Builds. Das sind spezielle Pakete des Ubuntu Kernelteams, die recht nahe am Original-Kernel sind. Ich versuchte wieder diverse Versionen. Alle brachten mir die Fehlermeldung. Na gut, dann baue ich eben einen eigenen Kernel.

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cp /boot/config-2.6.32-24-generic /usr/src/linux-2.6/.config
make oldnoconfig
make deb-pkg
dpkg -i ../linux*.deb
reboot

Beim ersten Reboot startete der Kernel tatsächlich korrekt. Sollte Ubuntu wirklich einen Bug in den eigenen Kernel eingebaut haben? Plötzlich fiel mir ein, dass die Zeile im grub einen kleinen, aber feinen Unterschied zu den restlichen Einträgen aufwies. Ich hatte root=/dev/sda1 angegeben. Alle anderen Einträge trugen root=UUID=.... Also versuchte ich die Änderung bei den anderen Kerneln und es klappte. Jede Kernelversion bootete mit dieser Änderung.

Jetzt muss ich nur noch herausfinden, warum das nicht klappt und ich bin wieder ein glücklicher Mensch.

Das Bild stammt vom Blog Linux und ich

Am Samstag mittag startet in Jena eine Kamerasafari. Die Guten und die Thüringer PIRATEN organisieren das Ganze. Alle Interessierten können sich am 26. Juni 2010 gegen 12:00 Uhr in der Löbderstraße (gleich vor an den Straßenbahnschienen). Von dort aus könnt ihr ausschwärmen und alle Überwachungskameras in Jena aufschreiben, fotografieren und dokumentieren. Das Ziel ist, dass meine Karte bzw. die von Martin Michel ausgebaut und aktualisiert wird. Ich würde mich über rege Teilnahme freuen!

Hast du dich gewundert, dass in der Logdatei von Tor viele Meldungen der Art [notice] Your IP address seems to have changed to 1.2.3.4.Updating. enthält? Dann könntest du einem Fehler in der Software aufgesessen sein. Ein Tor-Server, bei dem keine IP-Adresse fest eingestellt ist (Option Address) und dessen Hostname nicht/falsch auflöst, ermittelt seine IP-Adresse auf eigenwillige Weise. Es werden vier Byte aus dem Speicher ausgelesen und als IP-Adresse verwendet. Der Fehlerbericht 1269 hat eine Beschreibung. Mit Version 0.2.1.24 wurde das Verhalten wieder korrigiert.

In einem Moment von Langeweile blätterte ich in den Zahnärztlichen Mitteilungen. Diese Zeitschrift ist ein Fachblatt für Zahnärzte und behandelt neben der Standespolitik und Fachthemen auch interessante Nebenthemen wie Finanzen oder IT. In der Ausgabe 3 des laufenden Jahres gibt es einen Artikel zu One-Click-Hostern, wie Rapidshare. Gleich zu Anfang des Artikels ist zu lesen:

User X legt seine Daten - vom Röntgenbild bis zum Homemovie - auf einem Server im Internet ab [...]

Für mich sind die Daten bei One-Click-Hostern quasi öffentlich. Nun stelle sich mal vor, es etabliert sich bei Ärzten, Röntgenbilder und Patientenakten über Rapidshare zu tauschen. Dann ist gänzlich ohne elektronische Gesundheitskarte die Privatsphäre dahin ...

Gerade in einem Artikel für Ärzte wäre aus meiner Sicht mehr Sorgfalt angebracht und es sollte auf alle Risiken hingewiesen werden. Zwar gibt es am Ende des Artikels einen obligatorischen Hinweis auf Viren und Malware. Jedoch fehlt der wichtigere Hinweis, dass über derartige Plattformen auf keinen Fall Patientendaten getauscht werden sollten.

Wenn man das Interview mit zu Guttenberg liest, könnte man glauben, das zarte Pflänzchen Datenschutz beginnt auch bei der Regierung zu sprießen:

Ich glaube, dass man hochsensibel damit umgehen sollte und [..] manche vorauseilende Lust auf Daten auch einer solchen Überprüfung standhalten muss. Diese Prüfung ist vorzunehmen, und wenn ich Herrn Finanzminister Schäuble richtig verstanden habe, hat er sich schon sehr skeptisch geäussert. Ich kann diese Skepsis nur teilen.

Klingt doch gut, oder? Leider geht es Herr zu Guttenberg in dem Interview nur um die Kontodetails der Steuerbetrüger ...

via Computernotizen.

Steffen Schröder hat die Wahlprogramme von CDU/CSU und FDP mal nebeneinander gelegt und verglichen, wo Gemeinsamkeiten beim Datenschutz zu finden sind. Demnach wollen beide das Recht vereinfachen, Behörden und Datenschutzbeauftragte stärken sowie das Bewusstsein bei den Bürgern stärken. Ich bin gespannt, wie sich die Gemeinsamkeiten im Vertrag niederschlagen.

via Datenschutzbeauftragter Online.