Gebrauchte Daten kaufen

1 Reply

In den letzten Wochen habe ich für dienstliche Zwecke vier alte Speicherkarten vom Typ MMC gebraucht bei der elektronischen Bucht erstanden. Auf allen vieren waren noch Daten drauf. Sicher, die waren frisch formatiert, aber alle nur im Schnelldurchlauf. Neues Dateisystem anlegen und fertig. Kein einziger der Verkäufer hielt es für notwendig, wirklich alle Daten zu löschen.

Ich bin nun kein Forensiker und meine Zeit für solchen Spielkram ist begrenzt. Aber da ich den coolen Hex-Editor Bless sowieso installiert und Images der Karten angelegt hatte, um Partitionstabellen und Volume Boot Records zu untersuchen, hab ich natürlich noch kurz weiter über die Dumps geschaut. Beim wirklich nur flüchtigen drüber Gucken habe ich Kartendaten für ein Navigationsgerät, Musikdateien im mp3-Format und Tabellen mit Adressen von Ärzten1 gefunden. Gerade bei letzterem handelt es sich um sensible Daten, die man vermutlich nicht wissentlich weitergegeben hat. Da rollen sich mir ja dann schon die Fußnägel hoch.

Damit die ganze Aufregung hier nicht umsonst ist, noch ein kleiner Tipp, wie man hier zwei Fliegen mit einer Klappe schlagen kann. Man benutzt einfach das Tool badblocks unter Linux im Schreibmodus. Vorsicht ist angebracht, mit Datenträgern, die man noch braucht, wenn aber wirklich alles gelöscht werden kann, dann hier der Auszug aus der manpage mit der passenden Option:

-w Use write-mode test. With this option, badblocks scans for bad blocks by writing some patterns (0xaa, 0x55, 0xff, 0x00) on every block of the device, reading every block and comparing the contents.

Das Programm schreibt also bestimmte Muster auf die Karte und liest diese dann nochmal zurück und zwar für jeden einzelnen Block. Wenn Fehler dabei auftreten, werden die gemeldet und man kann den Datenträger wegwerfen. Wenn keine Fehler auftreten, kann man die Karte ruhigen Gewissens verkaufen und sicher sein, dass ausschließlich Nullen drauf stehen.

Ganz wichtig: damit das funktioniert, führt man badblocks mit root-Rechten aus und lässt es auf das ganze Device los. Da muss man vorher das passende rausfinden und 100% (und kein µ weniger) sicher sein, dass man das richtige erwischt hat. Wenn noch ein Filesystem auf der Karte ist, einfach mounten und mit mount nach dem Device gucken. Oder mit dmesg anzeigen lassen, wie die Karte beim Anstecken erkannt wurde. Oder aus /proc/partitions das Device mit der passenden Größe ablesen. Oder am besten alle Möglichkeiten zusammen. Der fertige Befehl in meinem Fall hier und heute:

badblocks -sw /dev/sde

Falls man nun gerade kein Linux zur Hand hat, bitte in Windows beim Formatieren unbedingt vermeiden die »Schnellformatierung« zu aktivieren. Oder am besten nach der Formatierung nochmal das Programm h2testw der c’t drüber laufen und Daten schreiben lassen, damit wenigstens die Adressdaten der Homöopathen verschwinden. Nicht dass die am Ende noch wer aufsucht, oder vermöbelt oder potenziert oder so …

Ach ja und abgesehen vom Verkaufen von alten Datenträgern: die erwähnten Programme sollte man auch auf jeden frisch neu erworbenen Datenträger loslassen, um sicherzugehen, dass der auch funktioniert. Ist mir nämlich in den letzten Wochen mit einer neuen Festplatte und einem neuen USB-Stick passiert, dass die gleich vom Start weg defekt waren und umgetauscht werden mussten.

  1. und Homöopathen, man beachte die Unterscheidung … ;) [↩]

Logitech-HID mit Debian Sid

1 Reply

Nutzer der Unstable-Variante von Debian (auch als Debian Sid bekannt) bekommen ja bekanntlich regelmäßig Gratisabenteuer aus dem Bereich der Systemadimistration geschenkt; sozusagen ein Quest-Abo.

Problem des Tages: Einen Systemstart nach dem letzten Update funktionierten Bluetooth-Tastatur und -Maus von Logitech nicht mehr, in meinem Fall konkret das Dinovo-Set.

Ich habe häufiger Ärger mit Logitech unter Linux, meistens ließ sich das aber mit einem Reset des Bluetooth-Dongles1 beheben. Dieses Mal nicht, der Fehler war persistent.
dmesg, logs und Modulliste waren soweit korrekt, es war alles da, was für die Geräte gebraucht würde und es wurde laut lsusb auch alles erkannt. Nur funktionierte einfach nichts. $SUCHMASCHINE lieferte dafür auch keine weiteren Ergebnisse.

Letztendlich habe ich das Problem in den udev-Regeln2, speziell der Datei 70-hid2hci.rules gefunden. Dort steht in Zeile 15:

RUN+="hid2hci --method=logitech-hid --devpath=%p"

Ein kurzer Blick auf die Manpage zeigt, dass der Aufruf nicht korrekt ist. Ich habe die Zeile so abgeändert:

RUN+="hid2hci --method=logitech --mode=hid --devpath=%p"

Seit dem funktionieren Tastatur und Maus wieder einwandfrei.

Die Regel deckt einen großen Bereich von Logitech-Produkten ab, das Problem tritt also wohl auch dort auf. Debian-Bugreport kommt dann später noch.

  1. Abziehen und wieder dranstecken. ;) [↩]
  2. zu finden unter /lib/udev/rules.d/ [↩]

Zurück im Jahr 2000 mit fli4l

Leave a reply

Ich befinde mich gerade auf den Chemnitzer Linux-Tagen 2010 am Stand von eisfair und fli4l. Unser überaus schicker Standrouter1 ist ein sogenanntes WRAP Board, also schon bisschen abgehangen. Der Hersteller hat hier leider keine Pufferbatterie für die RTC vorgesehen, so dass die Uhr nach jedem Stromausfall am 1.1.2000 um 0:00 (UTC) losläuft.

Nun läuft selbstverständlich fli4l (in der aktuellen Version 3.4.0) auf der Kiste und dort gibt es das Paket (bei fli4l traditionell opt genannt) chrony, was eben chrony bereitstellt, einen kleinen Dienst um die Zeit über NTP abzugleichen. Den Sprung von 2000 auf 2010 möchte der aber nicht automatisch abgleichen, so dass hier ein manueller Eingriff erforderlich ist. Die nötige Prozedur ist leider nicht ganz selbsterklärend, daher hier das kurze HowTo, wie man dort vorgehen kann.

Schritt 1: Den chronyd mit den richtigen Optionen neu starten. Per default wird dort bloß -r gesetzt. Die Option -s erlaubt auch das Setzen der RTC über chrony. Also erstmal per ssh einloggen. Dann:

killall chronyd
chronyd -r -s

Schritt 2: Beim chronyd einloggen. Dazu gibt man auf der Shell einfach chronyc ein. Per default darf man dann erstmal fast nichts, aber man kann das vom Paketmaintainer hinterlegte Passwort eingeben, um mehr Rechte zu erlangen. Bitte wie folgt eingeben:

chronyc
password dummy

Schritt 3: Die Zeit setzen. Dazu erlaubt man sich das zunächst mal mit dem Befehl manual, dann setzt man die Zeit und dann sagt man ihm noch, dass er das auch der RTC verklickern soll. Beim Setzen der Zeit reicht es das auf eine Minute genau zu machen, den Rest erledigt chrony später ganz normal per NTP.

manual on
settime 2010-03-14 08:55

Bei der Eingabe von settime springt die von chronyd erzeugte CPU-Last auf über 90%. Nach einem weiteren Neustart von chronyd, ist die Zeit gesetzt, ich kann nicht sagen warum, aber der pragmatische Ansatz funktioniert hier. Also:

killall chronyd
chronyd -r -s

Jetzt passt schonmal die Systemzeit, ein rtcdata im chronyc zeigt aber noch die alte Zeit der RTC. Also führt man hier nochmal ein trimrtc aus. Die Änderung braucht ein paar Minuten um übernommen zu werden, das geschieht aber dann automatisch.

So, und jetzt wo die Zeit vom Messerouter richtig eingestellt ist, freuen wir uns auf den zweiten Tag hier. Gestern war es schon gut besucht und es waren viele freundliche Interessenten am Stand. Der Sonntag Morgen läuft etwas ruhiger an, da könnte man eigentlich nochmal einen Kaffee trinken …

Update: die so gesetzte Uhrzeit übersteht auch einen Soft Reboot. D.h. wenn man das WRAP hinter eine USV hängt, braucht man die ganze Prozedur nur einmal auszuführen! ;-)

  1. wo alle Besucher nur fragen, wo man die Hardware kaufen kann [↩]

HowTo: Auf Kanal 13 funken mit Debian

Leave a reply

Unter uns sind neue Nachbarn eingezogen. Im Gegensatz zu den alten Nachbarn, verfügen diese über WLAN. Damit sind sie nicht die einzigen, im Funkspektrum tummeln sich hier ständig mindestens ein halbes Dutzend Funkzellen – kennt man vermutlich heutzutage aus jedem deutschen Mietshaus.

Grund genug für meinen Mitbewohner, den Kanal unseres WLAN-Access-Points mal in eine bisher wenig genutzte Region zu verschieben: Kanal 13. Nachtigall ick hör Dir trapsen, war da nicht mal was, mit Kanälen, die in den USA verboten sind, in Europa aber nicht? Muss wohl so sein, und da Debian ja fürsorglich ist, ist die Einstellung für USA default – obwohl, wenn man sich die Lösung ansieht, kann man Debian vermutlich nicht mal die Schuld in die Schuhe schieben.

Was also, wenn das Notebook jetzt nur Netze bis Kanal 11 anzeigt? Dann legt man unter Debian eine Datei in /etc/modprobe.d/ an. Wie die heißt, ist nicht so wichtig, bei mir heißt die wlan_EU.conf, auf .conf sollte sie wohl enden. Drin steht bei mir folgendes:

options cfg80211 ieee80211_regdom=EU

Eine Zeile, reicht aus. Die übergibt dem Kernelmodul cfg80211 beim Laden die passende Option und dann sind alle Kanäle sichtbar. An einigen Stellen im Weltnetz steht das “EU” noch in Anführungszeichen, also wenn’s ohne nicht klappt, dann vielleicht mit.

Xen: Debian Squeeze DomU in Debian Lenny Dom0

2 Replies

Aus der Reihe »Sonntag nachmittag für Frustrationstolerante« heute Folge 137 aus der Reihe »Virtualisierte Maschinen und freie Betriebssysteme«. Folgende Ausgangssituation: Server mit installiertem Debian Lenny als Xen Host (Dom0), es laufen diverse virtuelle Maschinen (DomU), unter anderem welche mit Debian Etch, eisfair-1, eisfair-2 und eben auch eine mit Debian Squeeze, dem aktuellen Testing-Zweig der Debian-Distribution. Bis auf die DomU mit eisfair-1 liefen alle virtuellen Maschinen bis dato mit dem Kernel 2.6.26-2-xen-686, der auch auf dem Host zum Einsatz kommt.

Vor einigen Tagen nun gab es in Debian Squeeze ein Update von udev 149 auf 150. Das Paket verweigerte dann aber die Installation mit dem Hinweis, dass der verwendete Kernel zu alt sei. Das war durchaus nervig, weil dadurch auch die Updates anderer Pakete nicht mehr eingespielt wurden, also hieß es: Kernel-Update.

Einfach mal schnell Kernel-Update gestaltete sich dann leider nicht so einfach. Debian hat Xen quasi aus der Distribution rausgeworfen bzw. bietet keine dedizierten Xen-Kernel mehr an. Gut, das ließ sich noch relativ problemlos lösen. Die Wahl fiel auf linux-image-2.6.30-bpo.2-686-bigmem von backports.org, denn dort heißt es:

This kernel also runs on a Xen hypervisor. It supports only unpriviledged (domU) operation.

Also fix den Kernel in der Dom0 installiert. DomU runtergefahren, Config angepasst, Kernelmodule ins Dateisystem der DomU kopiert, DomU gestartet und dann – nichts. Beim Hochfahren blieb die virtuelle Maschine einfach hängen, und zwar schon so früh im Bootprozess, dass ich keine Ahnung hatte, woran das lag.

Der nächste Schritt bestand dann darin eine weitere VM zum Testen aufzusetzen und die Suchmaschine der Wahl zu befragen. Ich weiß nicht, wo ich überall gelesen habe und was ich alles probiert habe. Am Ende funktionierte der Kernel, es waren nur Anpassungen an der Xen-Config notwendig, daher erstmal hier die Config und dann noch ein paar Kommentare dazu:

kernel  = '/boot/vmlinuz-2.6.30-bpo.2-686-bigmem'
ramdisk = '/boot/initrd.img-2.6.30-bpo.2-686-bigmem'
memory  = '128'
root    = '/dev/xvda1 ro'
disk    = [ 'phy:heaven/falbala_root,xvda1,w',
            'phy:heaven/falbala_swap,xvda2,w' ]
name    = 'falbala'
vif  = [ 'mac=00:16:3e:7d:4b:a2, bridge=eth0' ]
extra = 'xencons=hvc0 console=hvc0'
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

Wie man sieht, sind die Block-Devices, die in die VM gereicht werden, LVM Logical Volumes. Hier musste ich die Durchgereichten von /dev/sda* auf /dev/xvda* wechseln. Das hat definitiv mit dem verwendeten Kernel zu tun, der die Blockdevices nur noch dort ähm findet, oder so. Ich denke das war die entscheidende Änderung. In der mit »extra« beginnenden Zeile, habe ich die Angaben für die Xen-Konsole noch angepasst, irgendwo hatte ich gelesen, dass das jetzt hvc0 und nicht mehr xvc0 heißen muss. Die entsprechenden Änderungen an /etc/fstab und /etc/inittab innerhalb der virtuellen Maschine mussten natürlich auch noch vorgenommen werden, aber danach lief die DomU wieder und auch das Update von udev ließ sich problemlos einspielen. :-)

SpamAssassin: Von der Zeit eingeholt

Leave a reply

Heute kam die berechtigte Beschwerde eines Webserver-Mitnutzers, dass viele E-Mails neuerdings fehlerhaft als Spam klassifiziert würden. Als fähiger Informatiker hat er auch gleich noch ein Beispiel mitgeliefert. Darin wurde eine Regel sichtbar, die ich bislang noch gar nicht weiter beachtet habe und die bis zum Beginn dieses Jahres durchaus sinnvoll war:

FH_DATE_PAST_20XX

Diese Regel vergibt Punkte fuer alle E-Mails die ab dem 01.01.2010 datiert sind. Und nicht nur ein paar Zehntel, sondern bis zu 3.5 Punkte — bei insgesamt 5 nötigen Punkten für eine Spam-Klassifizierung macht das sehr viel aus. Effektiv wurde damit die Grenze für Spam auf 1.5 Punkte herabgesetzt.

Die Lösung ist im Apache-Wiki zu finden und wurde gleich noch mitgeliefert: In der lokalen Konfiguration muss diese Regel manuell deaktiviert werden, indem man die vergebenen Punkte auf 0.0 setzt. (Ein sa-update hatte bei mir keinen Effekt.)

Das ist mal ein schönes Beispiel dafür, dass insbesondere Regeln, die nicht global gültig sind und bleiben, regelmäßig begutachtet und gegebenenfalls überarbeitet werden müssen.

Coffee Connection: Netzwerkverbindungen mit Java im Debian Sid

8 Replies

Ein länglicher Titel für ein ärgerliches Problem mit kurzer Lösung:

Seit einigen Tagen mag sich Eclipse unter Debian Sid auf meinem Arbeitsnotebook nicht mehr mit dem Internet verbinden. Die Fehlermeldungen sind, je nach Modul, verschieden, laufen letztendlich aber immer auf etwas in der Form “Network noch reachable” hinaus. Erst dann fällt auch auf, wie oft ich doch bei der Entwicklung auf das Internet zugreife: Subversion und Maven funktionieren nicht mehr, Updates und das Einspielen von Plugins ist unmöglich und irgendwann – ein wichtiger Hinweis auf die Fehlerursache – stellte sich heraus, dass gar keine Java-Anwendung mehr Zugang zum Netzwerk hat.

Nachdem ich zunächst nach Fehlern bei Eclipse gesucht habe, war die Lösung nun recht nahe: Ein Blick in die Fehlerberichte für das Paket sun-java6-jdk zeigt den Bug #560044, der genau mein Problem beschreibt. Offenbar hält SUNs Java sich nicht an die Konventionen für den Umgang mit IPv4- und IPv6-Verbindungen, so dass IPv4 gar nicht mehr funktioniert.

Der Fehlerbericht enthält am Ende auch einen Workaround, der bei mir funktioniert: In der Datei /etc/sysctl.d/bindv6only.conf die Variable net.ipv6.bindv6only von 1 auf 0 setzen, und schon dürfen IPv6-Sockets auch IPv4-Pakete empfangen. [Update: Mit dem Aufruf invoke-rc.d procps restart muss die Konfiguration dann noch neu geladen werden.] Problem solved.

Nun muss dieser Bug nur noch unter dem Google-Query “Debian Eclipse network connection error” erscheinen, dann wäre er auch keinen Blogeintrag mehr wert. 8-)

Understanding the Perl/UTF-8 Madness

1 Reply

Ich habe gerade eine halbe Stunde damit verbracht, mal wieder diesem grandiosen xkcd-Comic gerecht zu werden. Los ging das mit einem Link, den ich bei qbi im Blog gefunden habe: Surviving the Perl/UTF-8 Madness. Der Name des Autors kam mir bekannt vor, ich glaube Tux hat ab und zu mal Links von dessen privatem Blog fallen lassen. Ich war also gespannt, was da kommt und wurde dann leider enttäuscht.

Worum geht’s? Es geht um Perl und wie Perl mit Encodings umgeht. Seit Perl 5.8 gibt es da ein sinnvolles Vorgehen, das sich aber anscheinend noch nicht rumgesprochen hat. Nachlesen kann man das sehr gut zusammengefasst im Tutorial perlunitut. Ich fasse das hier nochmal auf deutsch zusammen, weil es da anscheinend immer noch Missverständnisse gibt.

Wichtig zu wissen: Perl unterscheidet text/character strings von byte/binary strings (und das wirkt sich auf bestimmte Befehle wie print, uc, length usw. aus). Es wird häufig behauptet, die text strings wären UTF-8. Das mag so sein, ist aber völlig irrelevant und geht am eigentlichen Problem vorbei. Wie Perl diese text strings intern darstellt, kann einem total egal sein. Wichtiger ist, wie man damit umgeht und das fasst auch perlunitut korrekt zusammen:

  1. Receive and decode
  2. Process
  3. Encode and output

D.h. alles, was von außen kommt, egal ob von Nutzereingaben, aus Dateien oder Datenbanken, ist zunächst mal ein binary string. Wenn das Zeichenketten sind, mit denen ich Zeichenkettenoperationen durchführen will, muss ich die als erstes von byte strings in character strings umwandeln. Dazu kann ich binmode setzen, einen encoding Parameter bei open nutzen oder die decode-Funktionen aus dem Module Encoding bemühen, das ist faktisch alles das selbe, Tim Toady halt.

Der zweite Schritt ist klar: process, irgendwie auf den character strings rumackern. Beim dritten Schritt, dem output aus Perl raus dann der umgekehrte Weg: ich wandle meine character strings zurück in byte strings mit dem entsprechenden Encoding meiner Zielplattform, sei es nun STDOUT, ein file oder eine Netzwerkverbindung, egal und ebenfalls egal, ob das iso8859* oder UTF-8 oder sonstwas ist. Wenn man diese drei Schritte im Kopf behält und Worte wie utf-8 flag aus seinem Hirn streicht, kommt man mit Perl und Zeichensätzen klar.

Bisschen aufpassen muss man bei Fremdmodulen, da muss man im Zweifelsfall mal genauer hinsehen, wie die das handhaben. Was man vermeiden sollte: einfach davon ausgehen, dass Perl intern UTF-8 zur Repräsentation von character strings verwendet. Damit wird man über kurz oder lang auf die Nase fallen.

Neben perlunitut gibt es noch weitere gute Quellen zum Nachlesen:

Wenn man tiefer eintauchen will, kann man auch noch perlunicode oder perluniintro lesen, aber das ist dann schon harter Stoff. ;-)

Opera stellt fest

Leave a reply

Habe gerade Opera Update auf 10.10 eingespielt und bekomme gleich als erstes folgende Meldung:

Opera hat festgestellt, dass KDE läuft.

Einige von Operas Tastaturkürzel (wie Strg+F4) könnten nicht funktionieren, da KDE diese reserviert hat.

Sie können die KDE Tastenkürzel im KDE Kontrollzentrum ändern.

WTF? Ich werde doch nicht mein ganzes System umstellen, nur weil ein einziger proprietärer Browser da gern seine eigenen Tastenkürzel hätte. Zumal ich bei Opera sowieso immer das Problem habe, dass ich mit Tastenkürzeln, die ich aus anderen Programmen kenne, dort ins Leere laufe oder völlig unerwartete Sachen auslöse. Wieso schlägt Opera nicht vor, wie man seine eigenen Tastaturkürzel ändert? Frechheit! Naja, bleibt es halt weiterhin nur der billige Pornobrowser …

Wir haben einen Gewinner!

Leave a reply

Fast ein ganzes Jahr ist es her, dass wir am 11.11.2008 ein Gewinnspiel für ein T-Shirt ankündigten. Es gab einen Monat darauf eine einzige Erinnerung. Auf der Gewinnspielseite kann man sich nochmal kurz die Fragen ins Gedächtnis zurückrufen.

Infolge der Aufrufe erreichten uns insgesamt 7 Einsendungen per Mail. Zwei davon waren schlicht falsch, zwei mussten bedauerlicherweise wegen Insider-Wissen ausgeschlossen werden – die klassische Nummer halt: Verwandte, Mitbewohner und Haustiere der Veranstalter sind von der Teilnahme ausgeschlossen – und zwei waren direkt richtig. Die siebte Antwort ließen wir wegen profunder Literaturkenntnis und einem sich überraschend auftuenden zusätzlichen Zusammenhang ebenso gelten. Ich zitiere aus dieser Einsendung:

Die Antwort lautet natürlich 42, wie denn auch sonst. Dargestellt sind
Kastanien – mit denen kann man eine schöne Zeit verbringen.

Zu tun hat das ganze natürlich mit dem Anhalter. Zaphod erzählt darin,
dass er einen Megafrachter überfallen hat, um Kastanien zu erbeuten.

Gemeint ist das Buch »Per Anhalter durch die Galaxis« von Douglas Adams. Im Original ist von conkers die Rede, sozusagen horse chestnuts, also gewöhnlichen Rosskastanien der Gattung Aesculus (nicht zu verwechseln mit sweet chestnuts aka Esskastanien aka Castanea).

Doch wie lautete die von uns zuvor von uns erwartete Antwort auf die dritte Frage? Ich zitiere aus einer anderen richtigen Einsendung:

Die sieben Kastanien können als 0101010 interpretiert werden. Wenn das Binärcode sei, ist das dezimale Pendant die Zahl 42.

Goldrichtig! Nun war irgendwann die Zeit für die Einsendungen abgelaufen und wir konnten uns nicht so recht einigen, wann und wie wir das auslosen wollten. Im September packten wir dann die Gelegenheit beim Schopfe. Auf einer privaten Geburtstagsfeier waren zwei von drei der Initiatoren und zwei von drei potentiellen Gewinnern anwesend. Im Kreise dieser (und anderer) Zeugen wurde nach zuvor erfolgtem Mapping ein klassischer W6 Würfel ein einziges Mal geworfen, woraufhin dann der Gewinner fest stand.

Leider können wir kein Bild präsentieren, weil der Gewinner den Gewinn noch nicht eingelöst hat. Stattdessen gibt es das Motiv jetzt auch in einer englischen Variante, die unten abgebildet ist. Entsprechende Shirts sind weiterhin in unserem Shirtshop erhältlich.

Motiv Kastanien englisch

Alle Einsender werden mit Hinweis auf diesen Blogeintrag nochmal per E-Mail benachrichtigt.