seeseekey.net - Invictus Deus Ex Machina

Vor einigen Tagen schaute ich mir die Tasks unter einer Mac OS X Installation genauer an. Stutzig wurde ich bei einem Task in der Aktivitätsanzeige welcher folgenden Befehl ausführte:

sleep 31536000

Wenn man kurz nachrechnet wird man feststellen das dieser Sleep-Befehl einer Wartezeit von einem Jahr entspricht. Damit stellt sich die Frage was es mit diesem Befehl auf sich hat. Wenn man sich anschaut, wer für den Sleep-Befehl zuständig ist wird man feststellen das der GPG Agent diesen Befehl abgesetzt hat. Hintergrund für dieses Verhalten ist, das es nach Aussage der Entwickler keine einfachere Möglichkeit gibt ein Skript beim Herunterfahren des Systems auszuführen. Der entsprechende Commit im Repository erklärt das Verhalten genauer.

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.

Wenn man einen Server betreibt oder bei IT-Problemen zur Stelle ist wird man früher oder später mit dem Domain Name System, kurz DNS zu tun haben. Das DNS löst dabei Namen wie z.B. die Domain seeseekey.net zur passenden IP-Adresse (im aktuellen Fall: 138.201.85.250) auf. Unter Linux und Mac OS X gibt es für die Abfrage von DNS-Servern das Tool dig. Der domain information groper kann dabei im einfachsten Fall so genutzt werden:

dig seeseekey.net

Damit werden die DNS-Informationen der Domain ermittelt und ausgegeben. Die Anfrage richtet sich dabei an den lokalen DNS-Server. Möchte man die Informationen von einem anderen Server abrufen, so ist dies mit dig ebenfalls möglich:

dig @213.133.98.98 seeseekey.net

Die IP-Adresse 213.133.98.98 ist die Adresse des DNS Servers, welcher für die Abfrage genutzt wird. Die Antwort sieht für den Fall von seeseekey.net so aus:

; <<>> DiG 9.10.3-P4-Ubuntu <<>> seeseekey.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15428
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;seeseekey.net.                 IN      A

;; ANSWER SECTION:
seeseekey.net.          59795   IN      A       138.201.85.250

;; AUTHORITY SECTION:
seeseekey.net.          59795   IN      NS      robotns3.second-ns.com.
seeseekey.net.          59795   IN      NS      ns1.first-ns.de.
seeseekey.net.          59795   IN      NS      robotns2.second-ns.de.

;; Query time: 3 msec
;; SERVER: 213.133.98.98#53(213.133.98.98)
;; WHEN: Tue Aug 30 09:12:35 CEST 2016
;; MSG SIZE  rcvd: 156

In den letzten Tagen habe ich für ein Projekt einen REST-Server geschrieben. Der Server läuft unter .NET bzw. Mono – also war ich auf der Suche nach einer passenden Bibliothek bzw. einem Framework, welches mich bei dem Aufsetzen eines solchen Servers unterstützt. Nach einem Blick auf Nancy und einigen anderen Frameworks bin ich schlussendlich bei Grapevine gelandet.

sukona.github.io

sukona.github.io

Dabei handelt es sich um eine Bibliothek, welche neben einem REST-Client auch einen REST-Server bereitstellt. Das Hauptaugenmerk der Entwicklung wird dabei auf den REST-Server gelegt. Mit Hilfe des Frameworks lässt sich ein REST-Server mittels weniger Zeilen Quellcode aufsetzen:

ServerSettings settings = new ServerSettings();
settings.Host = "localhost";
settings.Port = "1111";

RestServer server = new RestServer(settings);
server.Start();

In diesem Beispiel werden die Einstellungen für den Server angelegt und anschließend dem Server übergeben. Danach wird der Server mit der Methode Start hochgefahren. Damit verfügt man zwar über einen REST-Server, dieser verfügt allerdings über keinerlei Methoden was die praktische Verwendung eher erschwert. Ressourcen für den Server werden mittels des Attributes RestResource markiert:

[RestResource(BasePath = "/time/")]
public class TimeModule
{
    [RestRoute(PathInfo = "date")]
    public IHttpContext GetDate(IHttpContext context)
    {
        context.Response.SendResponse(Grapevine.Util.HttpStatusCode.Accepted, getDate());
        return context;
    }
}

Über das Attribut RestRoute wird eine Methode für Grapevine gekennzeichnet – das Pathinfo definiert dabei den Pfad über welchen diese aufgerufen werden kann. Durch den über das Attribut RestResource festgelegten BasePath lautet die vollständige URL für die Ressource:

http://localhost:1111/time/date

Wird diese Methode per GET aufgerufen, so wird das aktuelle Datum zurückgegeben. Damit ist ein minimaler REST-Server mit einer Ressource implementiert. Grapevine selbst ist unter der Apache Lizenz lizenziert und damit freie Software. Der Quelltext der Bibliothek befindet sich auf GitHub.

Ab und an kommt es vor das man einen bootfähigen USB-Stick benötigt, z.B. um ein Live-Linux an einem Rechner ohne CD Laufwerk zu nutzen. Unter Windows kann man hierfür die Anwendung Rufus benutzen. Mit Hilfe von Rufus muss nur noch das entsprechende Laufwerk sowie einige Parameter eingestellt werden und anschließend wird der gewünschte Datenträger bespielt. Dabei unterstützt Rufus neben MS-DOS und FreeDOS beliebige ISO- und dd-Images.

Rufus

Rufus

Bezogen werden kann Rufus auf der offiziellen Webseite. Rufus ist freie Software und unter der GPL3 lizenziert. Der Quelltext ist auf GitHub zu finden.

Wenn man ein Android-Gerät gerootet hat, sind mit diesem einige Dinge möglich welche vorher nicht machbar waren. Unter anderem kann man den internen Speicher eines solchen Gerätes dumpen, das bedeutet ihn Bit für Bit in eine Image-Datei schreiben. Dazu verbindet man das gerootete Gerät mit dem Rechner und öffnet die ADB-Shell. ADB steht dabei für die Android Debug Bridge und befindet sich in den Plattform Tools des Android SDKs:

./adb remount
./adb shell

Kann die Verbindung nicht hergestellt werden, weil der ADB-Server bereits läuft, hilft es diesen vorher noch einmal zu beenden:

./adb kill-server

In der ADB-Shell gibt man nun su ein damit man auf der Root-Konsole landet. Anschließend kann man das Blockgerät welches für den internen Speicher steht auf die eingelegte SD-Karte schreiben. Dies geschieht dabei mit Hilfe des Befehls dd:

dd if=/dev/block/mmcblk0 of=/storage/extSdCard/imageInternalStorage.img

Probleme bekommt man bei diesem Prozess wenn das Image größer als 4 GiB ist. Da die SD-Karten meist standardmäßig mittels FAT32 formatiert sind, erlauben sie keine Dateien größer 4 GiB. Abhilfe schafft es hier die SD-Karte mit dem Dateisystem ext3 zu formatieren. Dieses kann von Android genutzt werden und erlaubt größere Dateien. Unter Umständen muss das ext3-Dateisystem dabei nochmals neu mit Schreibrechten eingebunden werden:

mount -t ext3 /dev/block/mmcblk1p1 /storage/extSdCard

Anschließend sollte das Image ohne Probleme geschrieben werden können. Je nach Größe und Geschwindigkeit der SD-Karte, kann der Prozess dabei einige Zeit in Anspruch nehmen. Nach der erfolgreichen Operation meldet dd-Vollzug und zeigt einige Statistiken zum Prozess an. Das Image kann nun von der SD-Karte auf den Rechner kopiert werden und dort z.B. dem FTK Imager gemountet und analysiert 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.

Den freien Suchserver Elasticsearch kann man, wie das Wort Suchserver es dezent andeutet, als Server betreiben. Allerdings ist es manchmal nicht gewünscht einen dedizierter Server zu betreiben. In einem solchen Fall kann man den Elasticsearch-Server in eine Java-Applikation einbetten. Der sicherlich häufigste Fall für eine solche Einbettung ist dabei die Nutzung zu Testzwecken (z.B. Unit-Tests zum Test der Suchergebnisse). Im ersten Schritt sollte in das Java-Projekt die entsprechende Abhängigkeit zum Projekt hinzugefügt werden. In diesem Beispiel wird dabei auf einem auf Maven basierenden Projekt ausgegangen – in diesem muss die pom.xml entsprechend erweitert werden:

<dependency>
    <groupId>org.elasticsearch</groupId>
    <artifactId>elasticsearch</artifactId>
    <version>2.3.4</version>
</dependency>

Damit wurde Elasticsearch dem Projekt hinzugefügt. Nun muss der eigentliche Server im Java-Projekt gestartet werden. Dafür werden nur wenige Zeilen Quellcode benötigt:

Settings.Builder elasticsearchSettings = Settings.settingsBuilder()
    .put("http.enabled", "true")
    .put("path.data", "data")
    .put("path.home", "home");

Node node = nodeBuilder()
    .local(true)
    .settings(elasticsearchSettings.build())
    .node();

In diesem Beispiel werden im ersten Schritt die Einstellungen für Elasticsearch definiert. Dabei wird unter anderem der HTTP-Modus aktiviert. Wenn dieser deaktiviert ist, ist die Kommunikation per HTTP nicht mehr möglich. Stattdessen kann dann nur noch die Kommunikation über das Transport-Interface genutzt werden. Dieses Interface wird im Normalfall für die interne Kommunikationen zwischen einzelnen Elasticsearch-Clustern genutzt – allerdings ist eine Nutzung mit dem Elasticsearch-Java-Client ebenfalls möglich. Mit dem aktivierten Modus, ist die Entwicklung einfacher (z.B. für den Einsatz von Analyse-Tools) und die Konfiguration näher an der Praxis. Standardmäßig horcht der Elasticsearch-Server dabei auf dem Port 9200 – in diesem Beispiel wäre er über die URL:

http://localhost:9200

erreichbar. Nachdem die Einstellungen angelegt wurden, werden diese dem NodeBuilder übergeben, welcher schlussendlich den Elasticsearch-Server hochfährt. Nachdem dieser hochgefahren wurde, kann die Nutzung des selben beginnen.

Wenn man Let’s Encrypt Zertifikate erzeugt, so landen diese im Ordner /etc/letsencrypt/. Die Rechte sind dabei so gewählt das nicht privilegierte Prozesse auf diese Zertifikate nicht zugreifen können. Läuft nun z.B. ein Server mit solchen Rechten, so kann er das Zertifikat nicht ohne weiteres nutzen. Um diesem Umstand zu beseitigen sollte eine neue Nutzergruppe angelegt werden:

groupadd tls-certificates

Dieser Gruppe wird nun der Nutzer hinzugefügt, welcher den Serverdienst betreibt:

usermod -a -G tls-certificates git

Damit wird der Nutzer git der Gruppe tls-certificates hinzugefügt. Nun müssen nach der Zertifikatsgenerierung die Berechtigungen angepasst werden:

#!/bin/sh
service gogs stop
letsencrypt renew --agree-tos
chgrp -R tls-certificates /etc/letsencrypt
chmod -R g=rX /etc/letsencrypt
service gogs start

In diesem Skript wird im ersten Schritt der Service gestoppt. Anschließend werden neue Zertifikate erzeugt und die Berechtigungen angepasst. Damit kann die Gruppe tls-certificates auf die Zertifikate zugreifen. Danach wird der Service wieder gestartet, was nun dank Zugriff auf die Zertifikate ohne Probleme funktioniert.

Möchte man bestimmte Seiten innerhalb eines WordPress umleiten, so gibt es neben der Möglichkeit dies über den Server zu tun, eine Reihe von Plugins. Für einen Einsteiger könnte die verwendete Syntax der meisten Plugins teilweise zu kompliziert (man denke nur an reguläre Ausdrücke und ähnliches) sein.

Simple 301 Redirects

Simple 301 Redirects

Einfacher kann diese Aufgabe mit dem WordPress-Plugin Simple 301 Redirects erledigt werden. Mit Hilfe des Plugins können einfach Umleitungen angelegt werden. Dabei werden Wildcards durch das *-Zeichen unterstützt und sind somit auch dem Einsteiger nutzbar. Das Plugin ist freie Software und unter der GPL2 (und neuer) lizenziert.

Preis: Kostenlos