seeseekey.net - Invictus Deus Ex Machina

Die freie Weltkarte OpenStreetMap ist über die Jahre immer größer, detailreicher und besser geworden. Wo Licht ist, ist allerdings auch Schatten zu finden. Beim OpenStreetMap sind dies – neben Edit-Wars und vielen (durchaus produktiven) Diskussionen – unbedachte Bearbeitungen, welche zu seltsamen Ergebnissen führen.

worstofosm.tumblr.com

worstofosm.tumblr.com

Eine Liste solcher Fehlschläge ist im Tumblr-Blog Worst of OSM zu finden. Von winzigen Häusern, interessant getaggten Imbissgelegenheiten bis zum Mißbrauch des freien Tag-Schemas ist dabei alles zu finden – damit findet der geneigte OpenStreetMap-Mapper seine tägliche Portion Grusel.

Wenn man längere Zeit mit Git arbeitet, wird einem die eine oder andere seltenere Fehlermeldung über den Weg laufen. Eine dieser Fehlermeldungen ist:

fatal: multiple stage entries for merged file 'DBAdapter.cs'

Hintergrund bei diesem Problem ist das der Index, welcher die Änderungen und Dateien enthält mit welchem der nächste Commit erstellt wird, für eine Datei mehrere Einträge vorhält; was per Definition nicht der Fall sein sollte. Der Workaround für diese Problem besteht darin, den Index (bzw. die sogenannte Staging area) zu löschen, die Dateien erneut hinzuzufügen und das ganze mit einem Commit in Stein gießen:

rm .git/index
git add -A
git commit -a

Anschließend kann das Git-Repository wieder ohne Probleme genutzt werden.

Vor einigen Tagen begegneten mir einige Dateien, deren Inhalts größtenteils aus der Zeichenfolge EF BF BD EF BF BD EF BF BD (hexadizimal) bestand. Eigentlich sollte in den entsprechenden Dateien binäre Daten enthalten sein. Damit stellte sich nun die Frage: Was war passiert?

EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD

Auf den ersten Blick sah das ganze so aus, als ob ein Großteil der Datei durch Datenmüll ersetzt wurde. Schaut man sich die Zeichenfolge allerdings genauer an, so wird man feststellen das sich die Folge EF BF BD immer und immer wieder wiederholt. Bei dieser Zeichenfolge handelt es sich um die hexadezimale Schreibweise des Unicode-Zeichens für den Replacement Character welcher meist durch eine Raute mit einem Fragezeichen (�) dargestellt wird.

Eindeutiger wäre das Problem gewesen, wenn die erzeugten Dateien mit der Zeichenfolge EF BB BF begonnen hätte. Dabei handelt es sich um das Byte Order Mark für eine UTF-8 kodierte Datei. Damit wäre gleich klar geworden, das die enthaltenen Daten nicht zu einer Datei mit binären Inhalten passen. Doch wie sind diese Dateien nun entstanden? Der Ursprung der Dateien ist in einer Java-Applikation zu finden, welche diese Dateien erstellt. Diese kopierte die Daten von A nach B, im Quelltext (man ignoriere das fehlende try with resources) könnte das so ausgesehen haben:

FileInputStream fileInputStream  = new FileInputStream("binary.dat");
FileWriter fileWriter = new FileWriter("binary-copied.dat");

int byteData;

while ((byteData = fileInputStream.read()) != -1) {
    fileWriter.write(byteData);
}

fileInputStream.close();
fileWriter.close();

Hier wird ein FileInputStream geöffnet und dieser Stück für Stück mit einem FileWriter in die Zieldatei geschrieben. Genau an dieser Stelle entsteht das Problem – der FileWriter ist nämlich ein zeichenbasierter Writer, das bedeutet das sämtliche Zeichen, die mit diesem geschrieben werden, kodiert werden. Wenn nun bei dieser Kodierung ein Zeichen gefunden wird, welches nicht im Unicode abgebildet werden kann, so erhält dieses Zeichen den Wert EF BF BD – besagter Replacement Character. Damit ist dann auch erklärt warum die binären Dateien hauptsächlich nur noch aus diesen Zeichen bestanden. Die echten Daten wurden beim Kopiervorgang größtenteils schlicht und ergreifend in den Replacement Character konvertiert, da sich für diese Daten keine Entsprechung im Unicode fand.

Wenn man Dateien mit dem Midnight Commander von A nach B kopiert kann es passieren das man mit der Fehlermeldung:

Cannot chown target directory

konfrontiert wird. Das Problem ist das beim Kopieren die Attribute der Dateien ebenfalls übernommen werden. Dazu kopiert der Midnight Commander die Datei zum Zielort und versucht anschließend die Attribute anzupassen. Hierbei kann es passieren, das das Ziel die Anpassung der Attribute nicht unterstützt – dies führt zu besagtem Fehler.

Der Midnight Commander beim kopieren

Der Midnight Commander beim kopieren

Umgehen lässt sich der Fehler in dem im Kopierdialog der Punkt Attribute sichern deaktiviert wird. Damit werden die Dateien nur noch kopiert; eine Attributänderung findet nicht mehr statt.

Unter Umständen kann es unter Ubuntu, oder anderen Distributionen basierend auf Debian passieren, das ein apt-get Vorgang fehlschlägt. Dies kann sich darin äußern das apt-get nicht mehr genutzt werden kann – stattdessen bekommt man folgende Meldung zu sehen:

E: Could not get lock /var/lib/dpkg/lock - open (11 Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/) is another process using it?

Hintergrund ist das dpkg Sperrdateien mit dem Name lock anlegt und sie nach getaner Arbeit wieder entfernt. Bei plötzlichen Unterbrechungen wie z.B. einem Stromausfall kann es passieren das die Dateien nicht mehr entfernt werden. Lösen kann man das Problem indem man die entsprechenden Sperrdateien entfernt:

rm /var/lib/dpkg/lock
rm /var/lib/apt/lists/lock
rm /var/cache/apt/archives/lock

Abschließend sollte dpkg bzw. apt-get wieder ohne Probleme funktionieren.

Vor einigen Tagen migrierte ich einen Minecraft-Server von einem Server mit Ubuntu 14.04 LTS auf einen Server mit Ubuntu 16.04 LTS. Der Minecraft-Server lief dabei auf dem alten als auch auf dem neuen Server jeweils in einer KVM-Gast-Maschine. Er startete ohne Probleme und wenn man sich das ganze von außen mit nmap anschaute, war der entsprechende Port auch offen gekennzeichnet. Allerdings konnte der Minecraft-Client keinerlei Verbindung mit dem Server aufnehmen. Lösen ließ sich das Problem mit der Änderung einer Einstellung in der server.properties Datei. Konkret ging es dabei um die Einstellung:

use-native-transport = true

welche auf false gesetzt werden musste. Mit diesem Flag wird das optimierte Senden und Empfangen von Paketen unter Linux deaktiviert. Damit funktionierte der Minecraft-Server wieder ohne Probleme.

Wenn man ein CentOS 7 in der Minimal-Installation installiert (und dabei nicht aufpasst), wird man nach der Installation feststellen das man über keine Konnektivität verfügt. Das ist bedingt dadurch das die entsprechende Netzwerkschnittstelle beim Booten nicht konfiguriert wird. Um die Schnittstelle zu konfigurieren, sollte im ersten Schritt in den entsprechenden Ordner gewechselt werden:

cd /etc/sysconfig/network-scripts/

In diesem Ordner befindet sich eine Datei ifcfg-eth0 (alternativ sind auch andere Schnittstellennamen wie ifcfg-enp0s3, em1 und ähnliche möglich). Die entsprechende Datei wird nun mittels vi geöffnet:

vi ifcfg-eth0

In dieser Datei gibt es eine Option mit dem Namen ONBOOT, deren Wert standardmäßig auf no gestellt ist. Dieser Wert muss in yes geändert werden und anschließend die Datei gespeichert werden (:w zum Speichern der Datei, :q um VIM zu schließen). Nach einem anschließenden Neustart, sollte die Netzwerkschnittstelle konfiguriert und funktionsfähig sein.

Die Magic Mouse von Apple ist mittels Bluetooth an den Rechner angebunden und funkt auf einer Frequenz von 2,4 Ghz. Unter Umständen kann es passieren das diese Frequenz gestört wird. Dies kann zu Aussetzern führen, welche sich darin äußern das die Verbindung der Maus mit dem Rechner unterbrochen wird.

Eine Magic Mouse von Apple

Eine Magic Mouse von Apple

Eine Ursache für dieses Problem kann ein bestehendes WLAN sein, welches auf einem der höheren Kanäle (7 – 13) betrieben wird. In einem solchen Fall kann es hilfreich sein den Kanal des 2,4 Ghz WLANs auf einen der niedrigen Kanäle einzustellen. Dies verringert die Störungen welche zwischen dem WLAN und dem Bluetooth auftreten können.

Der Passwortmanager 1Password nutzte in den letzten Jahren das AgileKeychain-Format zur Speicherung der Daten bei einer Sychronisierung über Dropbox. Das Problem an diesem Format ist das bestimmte Metadaten wie der Titel und URL im Klartext in diesem Format stehen. Allerdings gibt es bereits seit 2012 das OPVault-Format welcher ohne diese Schwäche auskommt. Möchte man das Format unter 1Password 5 für Mac OS X umstellen, so muss im ersten Schritt die Dropbox-Synchronisation deaktiviert werden und die Daten in der Dropbox gelöscht werden. Besitzt man die Appstore-Version von 1Passwort so gibt man im Terminal anschließend:

defaults write 2BUA8C4S2C.com.agilebits.onepassword-osx-helper useOPVaultFormatByDefault true

ein. Nutzt man hingegen die Version von der Webseite, so muss stattdessen:

defaults write 2BUA8C4S2C.com.agilebits.onepassword4-helper useOPVaultFormatByDefault true

eingegeben werden. Danach kann die Synchronisation wieder aktiviert werden. Sie erfolgt nun im OPVault-Format. In der nächsten stabilen Version von 1Passwort kann diese Aufgabe auch über das Menü (Help -> Tools -> Enable OPvault for Dropbox and Folder sync) erledigt werden.

Nachdem ich die aktuelle Version von LibreOffice installiert hatte und ein Dokument mit einem Bild verfassen wollte, stellte ich fest das es ein Problem mit der Darstellung von Bildern gibt. Es wurde nur noch der Rahmen aber nicht mehr der Inhalt dargestellt.

Das Bild wird nicht dargestellt

Das Bild wird nicht dargestellt

Ursache für das Problem ist eine deaktivierte Checkbox in den Optionen. Öffnet man die Einstellungen unter Extras -> Optionen -> LibreOffice Writer gibt es im Punkt Ansicht die Checkbox Grafiken und Objekte im Punkt Anzeigen.

Die Checkbox Grafiken und Objekte ist deaktiviert

Die Checkbox Grafiken und Objekte ist deaktiviert

Nachdem die Checkbox wieder gesetzt ist, zeigt LibreOffice wieder wie gewohnt Bilder an.