Wikipad: Etherpad-Lite mit DokuWiki synchronisieren

Vor einiger Zeit habe ich mir ein Etherpad-Lite installiert, um verteilt und auch unterwegs Texte verfassen zu können, die ich anschließend veröffentliche oder anderweitig nutze. Das ist soweit toll, doch die Veröffentlichung war in meinen Augen unpraktischer, als sie sein müsste, da ich den Text kopieren, irgendwo anders einfügen und neu formatieren musste.

Meine Idee war es, die Veröffentlichung direkt aus dem Etherpad-Lite heraus erledigen zu können - zum Beispiel bei kleineren Texten, die ich anderen zur Verfügung stellen möchte. Die Frage war nur, über welche Plattform die Veröffentlichung stattfinden sollte.

Anfang dachte ich daran, eine eigene Oberfläche zu entwickeln, allerdings wäre die nicht sonderlich hübsch geworden. Vor kurzem bin ich nun auf DokuWiki gestoßen, das perfekt zu sein schien. Das besondere an DokuWiki ist, dass keine Datenbank verwendet wird, sondern alle Inhalte in einfachen *.txt-Dateien abgelegt werden. Ich könnte also einfach Pads exportieren, als Textdatei ablegen und wäre fertig: Die Idee zu Wikipad war geboren.

Formatierung in Etherpad-Lite

Formatierung in Etherpad-Lite

Implementiert habe ich die Synchronisation in PHP. Das Vorgehen ist relativ einfach. Es gibt einen Pad-Präfix und einen Wiki-Präfix. Alle Pads, die den Pad-Präfix ("<Pad-Präfix>!<Name>") beinhalten, werden in einen Namespace des Wikis überführt ("<Wiki-Präfix>:<Name>"). Man kann die Präfixe auch weglassen, dann werden diese ignoriert und ohne Präfixe gearbeitet. In meinem Fall verwende ich z.B. den Pad-Präfix "wiki!" und einen leeren Wiki-Präfix.

Als erstes lasse ich aus der Etherpad-Lite Datenbank auslesen, welche Pads es mit dem Pad-Präfix gibt. Anschließend wird geprüft, wieviele Revisionen es von diesem Pad gibt. Hat sich seit der letzten Synchronisation die Anzahl der Revisionen geändert, so wird das Pad exportiert und in den data-Ordner des DokuWikis geschrieben.

Formatierung in DokuWiki

Formatierung in DokuWiki

In meinem Fall befindet sich die Instanz des Etherpad-Lite unter pad.nix.li hinter einer Authentisierung. Die DokuWiki-Instanz hingegen befindet sich unter wiki.nix.li und ist ohne Authentisierung erreichbar.

Neben den Präfixen habe ich noch ein paar weitere Steuerungsmechanismen implementiert. So werden Pads nichts synchronisiert, wenn sie direkt nach dem Präfix einen Punkt im Namen haben (z.B. "wiki!.beispiel").

Zudem ist es möglich, inline (das heißt im Content des jeweiligen Pads) die Synchronisation eines Pads zu beeinflussen. Damit ein Pad aus dem Wiki gelöscht wird, muss der Padinhalt dazu mit dem Text [.remove] beginnen. Möchte man stattdessen ein Pad bearbeiten, ohne, dass die aktuell gültige Fassung im Wiki gleich mitbearbeitet wird, so muss der Padinhalt mit dem Text [.ignore] beginnen. In diesem Fall bleibt die aktuelle Seite im Wiki erhalten, wird jedoch nicht mit der neusten Revision des Pads überschrieben.

Den Quelltext von Wikipad findet ihr unter hg.nix.li/wikipad. Dabei handelt es sich um ein Mercurial-Repository. Ihr könnt es also einfach mit folgendem Befehl auf euren Computer kopieren, wenn ihr Mercurial installiert habt:

1
hg clone http://hg.nix.li/wikipad/

Ich hoffe, Wikipad kann euch von Nutzen sein. :)

Synchrone Grüße, Kenny

P.S.: Der umgekehrte Weg, Inhalte vom DokuWiki nach Etherpad-Lite zu synchronisieren, ist derzeit nicht implementiert.

Heartbleed – Problem oder Chance?

Der Heartbleed-Angriff, der letzte Woche veröffentlicht wurde, hat die Grundfeste der IT-Security erschüttert. Alle möglichen Technologiemedien haben sich auf das Thema gestürzt und auch in der Community ist neue Bewegung in das Thema Infrastrukturgrundlagen gekommen. Doch was ist überhaupt los?

Bei OpenSSL handelt es sich um eine OpenSource-Bibliothek, die grundlegende Funktionen für die verschlüsselte Kommunikation im Internet bereitstellt. Diese Bibliothek wird von vielen Anwendungen verwendet, die verschlüsselt über das Internet kommunizieren müssen. Genau in dieser Bibliothek wurde ein schwerwiegender Fehler gefunden.

Bei XKCD ist dazu ein einfach zu verstehender Comic erschienen. Im Grunde passiert folgendes: Damit ein normaler Nutzer herausfinden kann, ob die Verbindung zu einem Server noch besteht, kann man ihm einfach eine beliebige Nachricht schicken. Erhält man die gleiche Nachricht zurück, ist der Server offenbar noch erreichbar.

In der bisherigen Implementierung war jedoch eine riesige Lücke. In der Anfrage des Nutzers gibt der Nutzer selbst an, wie lang die Daten sind, die zurückgeschickt werden sollen. Der Server glaubte dieser Angabe und schickte genau so viele Daten aus seinem Speicher zurück - auch dann, wenn die Daten, die der Nutzer wirklich geschickt hat, viel kürzer waren. Das führte dazu, dass Daten an den Nutzer geschickt wurden, die ihn gar nicht betreffen, wie z.B. Zugangsdaten fremder Nutzer.

Seit dem Bekanntwerden haben alle möglichen Medien über das Thema berichtet - teils werden Horrorszenarien verbreitet. Doch auch in Kreisen, die sich mit der Materie auskennen, ist man beunruhigt. Wenn solch ein schlampiger Fehler in einer der wichtigsten Bibliotheken des WWW seit 2 Jahren unentdeckt vorhanden war, was mag dann noch alles im OpenSSL-Quelltext auf uns warten?

Inzwischen werden Rufe danach laut, dass man OpenSSL einmal vollständig auditieren sollte - sprich: dass jemand den gesamten Quelltext auf mögliche Fehler hin überprüfen sollte.

In meinen Augen ist das ein aussichtsloses Unterfangen. Wer sich schon einmal die Mühe gemacht hat, sich allein in die OpenSSL-API einzulesen, weiß, was ich meine. Die gesamte Bibliothek ist im Grunde ein riesiger, komplexer Bloat, mit zig internen Abhängigkeiten, später hinzugefügten Laschen und Ösen und ist nur schwer zu durchdringen.

Mitunter wird empfohlen, nicht direkt OpenSSL einzusetzen, sondern einen Wrapper zu nutzen, der die Komplexität verschleiert. In meinen Augen ist das ein Armutszeugnis. Es gibt Ecken, in denen das ganze besser funktioniert - zum Beispiel bei den Ciphersuits. Anstatt sich selbst zu überlegen, was funktionieren könnte und was wohl eine starke Kombination ist, kann man sich einfach eine sortierte Liste der möglichen Kombinationen ausgeben lassen und diese nutzen.

Meiner Meinung nach müsste OpenSSL generell diese Möglichkeit bieten. Es sollte einfach sein, mit wenig Aufwand einen sicheren Kanal zu erhalten. Man muss es hinkriegen, dass es schwieriger ist, es falsch zu machen, als es richtig zu machen. Das setzt jedoch voraus, dass man einige Teile grundlegend neu schreibt. Auch der Einsatz modernerer, sicherer Programmiersprachen wäre ein Schritt in die richtige Richtung.

Die Frage, wer nun Schuld an der Misere hat, stellt sich in meinen Augen hingegen nicht. Ja, der Entwickler, der den Code eingestellt hat, arbeitet inzwischen bei einer Telekom-Tochter. Ja, der Reviewer, der den Code akzeptiert hat, hätte den Fehler sehen müssen. Jedoch bleibt OpenSSL primär eines: eine frei verfügbare Implementierung, mit offen zugänglichem Quelltext, der jedem die Möglichkeit gibt, Fehler zu finden. Wir sollten zusehen, dass die Komponenten, die für unseren Alltag so wichtig sind, mehr engagierte Entwickler zur Verfügung haben.

Was nun zu tun bleibt:

  • Jeder, der eine verwundbare OpenSSL-Version einsetzt, muss diese patchen.
  • Jeder, der eine verwundbare OpenSSL-Version patchen musste, muss neue Schlüsselpaare erzeugen.
  • Jeder, der neue Schlüsselpaare erzeugen musste, muss sich für diese neue Zertifikate ausstellen lassen.
  • Jeder, der sich neue Zertifikate ausstellen lassen musste, muss seine alten Zertifikate revoken lassen.
  • Jeder, der seine alten Zertifikate revoken lassen musste, muss seine Nutzer informieren und zur Änderung ihrer Passwörter aufrufen.

Es bringt derzeit nichts, vorsorglich seine Passwörter zu ändern. Solange die Server noch verwundbar sind, können auch neu gesetzte Passwörter wieder gestohlen werden. Langfristig ist es zudem angebracht, für jeden Dienst ein eigenes Passwort zu verwenden. So sind Dienste, die nicht von der OpenSSL-Lücke betroffen sind, gar nicht erst in Gefahr. Helfen können dabei Lösungen wie z.B. calc.pw. ;)

Herzblutende Grüße, Kenny

P.S.: Für meine Server habe ich bereits alles erledigt. Gepatcht, Schlüssel erzeugt, neue Zertifikate erstellt, alte Zertifikate revoked und die Nutzer mit Logins informiert und zum Passwortwechsel aufgerufen.

The Micro: Kleiner 3D-Drucker mit großem Potential

Auf Kickstarter läuft derzeit eine Kampagne zum The Micro, einem kleinen 3D-Drucker der Firma M3D, der derzeit für Furore sorgt. Für derzeit $299 plus Versand soll man Ende des Jahres einen fertig zusammengebauten, stylischen, stromsparenden 3D-Drucker erhalten, der im Gegenzug kleiner ausfällt als seine 4 bis 5 Mal so teure Konkurrenz zum selber bauen.

meet the micro

meet the micro

Das ursprüngliche Finanzierungsziel von $50.000 war bereits nach sensationellen 11 Minuten erreicht, derzeit hat man eine Summe von über zwei Millionen Dollar eingenommen - das 40-fache des anvisierten Ziels. Grund für den Blitzstart war sicherlich auch, dass die Macher bereits vorher die Werbetrommel gerührt hatten. Bereits im Februar gab es die ersten Berichte und auch ich hatte mich vorzeitig zum Newsletter angemeldet, um zu erfahren, wann es genau losgehen würde. Leider hatte ich das Super Early Bird Special für $199 verpasst, da ich zum Startzeitpunkt auf Arbeit war. Zumindest habe ich mir einen Drucker für $299 ergattert können, der nun hoffentlich im November 2014 geliefert wird.

Häufig wird die Frage gestellt, was denn eine Privatperson mit einem 3D-Drucker anfangen soll, zumal die maximale Baugröße des The Micro durchaus eingeschränkt ist.

Tastenkopf

Tastenkopf

Ich jedenfalls habe bereits explizite Ideen. Für meine calc.pw Tastatur, an der ich derzeit arbeite, benötige ich Tastenköpfe für die Cherry-Tastaturschalter, die ich verbauen möchte. Derzeit behelfe ich mir mit den Tastaturköpfen von gekauften Tastaturen, zukünftig will ich sie hingegen selbst herstellen. Auch hoffe ich, mir damit Gehäuse für aktuelle und zukünftige Projekte basteln zu können.

Wer noch einen günstigen Einstieg in die Welt des 3D-Drucks sucht, sollte sich den Micro-Drucker einmal genau ansehen. Von den Geräten, die im Januar 2015 geliefert werden sollen, sind derzeit noch etwa 1300 Stück übrig. Die Kampagne bei Kickstarter läuft noch bis Anfang Mai.

Mit Zollproblemen wie bei der Pebble wird man hoffentlich nicht zu kämpfen haben. Die Macher des The Micro haben das Thema Versand bereits ausführlich in einem Update angesprochen. Man wird mit Importeuren zusammenarbeiten, die sich um Dinge wie Verzollung und Versteuerung kümmern sollen.

Auch die Themen Ersatzteile und Filament wurde bereits in einem Dokument angesprochen. Man plant, Ersatzteile zu akzeptablen Preisen anzubieten. Beim Filament hat man zwei Möglichkeiten: Entweder man verwendet Filament-Rollen in Standardgröße oder aber man bestellt direkt bei M3D kleinere Spulen, sich im Boden des Micro-Druckers verstauen lassen. Auch deren Preise liegen mit derzeit $12 je Rolle im normalen Bereich - zur Not lässt sich auf die kleineren Spulen einfach separat gekauftes Filament wieder neu aufrollen.

Ich jedenfalls freue mich bereits darauf, bald meinen The Micro 3D-Drucker mitsamt den von mir mitbestellten Filament-Spulen in Empfang nehmen zu können. :)

Dreidimensionale Grüße, Kenny

WeizenSpr.eu in neuen Kleidern

Vor nun etwas mehr als 5 Jahren ist der Blog WeizenSpr.eu gestartet. Anfangs noch mit dem Default-Theme Kubrick ausgestattet, wechselte ich irgendwann zum Mainstream-Theme von WooThemes, mit dem ich die letzten Jahre über sehr glücklich war. Das Theme wird inzwischen jedoch nicht mehr gepflegt und auf der WooThemes-Webseite ist es auch nicht mehr auffindbar. Ein neues Theme musste her.

Ich probierte das Simple-Theme von ThemeSmarts aus und war von der Optik relativ angetan. Allerdings stellte sich schnell heraus, dass die Entwickler nicht sonderlich viel Mühe in ihre Arbeit gesteckt haben. So wimmelte das eingesetzte JavaScript nur so vor Bugs - nicht einmal das Ausklappen des Menüs funktionierte - und hier und da gab es Probleme mit dem CSS. Es war viel Handarbeit nötig, um das Theme ordentlich einsetzen zu können. Zu viel in meinen Augen, um dem Theme vertrauen zu können.

Also machte ich mich wieder auf die Suche, dieses Mal entschlossen, zur Not Geld in die Hand zu nehmen. Gelandet bin ich bei einem kleinen Designstudio aus Stuttgart: elmastudio. Dieses bietet eine handvoll hübscher Themes in ihrem Theme-Bundle für 36€ an.

Dabei ist auch das Waipoua-Theme, das ich nun einsetze. Es ist sauber programmiert und benötigte nur wenige Design-Anpassungen, damit es meinem Geschmack entsprach. Das schöne ist, dass es sich um ein responsive Design handelt, was bedeutet, dass es auf allen möglichen Displaygrößen funktioniert und immer ein ähnliches visuelles Erlebnis ermöglicht. Damit sind die Tage von zwei verschiedenen Designs (Desktop und Mobile) vorbei! :D

Auch etwas anderes ist nun vorbei: Der Einsatz von BBCode in den Kommentaren! Als ich diesen 2009 hier im Blog einführte, war WordPress anfällig für JavaScript in den Kommentaren. An dieser Front hat sich in den vergangenen 5 Jahren jedoch einiges getan. Die alten Kommentare habe ich bereits auf HTML umgestellt. Welche HTML-Elemente in den Kommentaren zulässig sind, könnt ihr unter dem Kommentarfeld sehen. :)

Und das beste von allem: Mit dem neuen minimalistischeren WordPress-Theme kommt auch das neue, minimalistischere WeizenSpr.eu-Logo besser zur Geltung. :)

Was denkt ihr? Könnt ihr euch mit dem neuen Design anfreunden? :)

Durchgestylte Grüße, Kenny

Serverüberwachung mit Mercurial

Verteilte Versionsverwaltungen sind mächtige Werkzeuge. Sie kommen ohne Serverinfrastruktur aus und können für so ziemlich alles verwendet werden, wo man gern verschiedene Dateistände vorhalten möchte. Je nach Anwendungsfall sind diese Tools sehr einfach einzusetzen. Mein Liebling hierbei ist zur Zeit Mercurial, das sowohl für Windows, Linux als auch MacOS verfügbar ist.

Die Anwendung ist eigentlich kinderleicht: Zuerst einmal muss man ein Repository anlegen. Dazu geht man in einen Ordner, dessen Änderungen man gern verfolgen möchte und führt den Befehl "hg init" aus. Dabei wird ein ".hg"-Ordner angelegt, in dem sich alle relevanten Informationen befinden. Anschließend kann man via "hg add" alle Dateien im aktuellen Ordner dem Repository hinzufügen. Mit "hg commit" erstellt man seine erste gesicherte Version.

Nun kann man beliebig im Ordner weiterarbeiten. Wenn man wissen möchte, was sich seitdem geändert hat, kann man sich mit "hg status" die Liste der geänderten Dateien ausgeben lassen. Mit "hg diff" ist es sogar möglich, Änderungen innerhalb der Dateien zu vergleichen. Sollten einem Änderungen nicht gefallen, kann man mit "hg revert" zur letzten gesicherten Version zurückkehren. Will man die Änderungen stattdessen behalten, führt man wieder ein "hg commit" aus und erstellt eine neue gesicherte Version.

Mit diesem Grundwissen (und etwas PHP) lässt sich bereits eine einfache Serverüberwachung realisieren. Wie das funktioniert, werde ich einmal beispielhaft an den beiden Ordnern "/var/www/example_com/" und "/var/www/example_net" zeigen.

Als allererstes müssen wir einmal die benötigten Tools installieren:

1
2
sudo apt-get update
sudo apt-get install mercurial php5-cli

Als nächstes müssen wir in die jeweiligen Ordner gehen und dort die Repositories anlegen. Zudem legen wir noch jeweils eine Datei ".hgignore" an, um Dateien und Ordner aus der Überwachung ausschließen zu können (z.B. temporäre Ordner, die sich permament ändern könnnen):

1
2
3
4
5
6
7
8
9
10
11
cd /var/www/example_com/
sudo hg init
sudo chmod 700 ./.hg/
sudo touch ./.hgignore
sudo chmod 600 ./.hgignore

cd /var/www/example_net/
sudo hg init
sudo chmod 700 ./.hg/
sudo touch ./.hgignore
sudo chmod 600 ./.hgignore

Die benötigten Dateien gehören root, damit ein Angreifer diese nicht einfach lesen, löschen oder bearbeiten kann. Das ist nicht weiter tragisch, da wir die regelmäßige Prüfung via Cron durchführen werden. Natürlich kann man hier auch einen separaten Nutzer für verwenden. Folgenden Inhalt habe ich typischerweise in meiner ".hgignore"-Datei, aufgrund der chroot-Umgebung:

1
2
3
4
5
6
7
syntax: glob
mysql/mysql.socket
tmp/*
dev/null
dev/random
dev/urandom
dev/zero

Wenn wir fertig sind, können wir das jeweilige Repository mit Dateien befüllen. Dabei werden die Dateien ignoriert, die wir über die Datei ".hgignore" ausgeschlossen haben. Anschließend erstellen wir unseren ersten, initialen Commit. Damit sichern wir die aktuelle Version des Repositories:

1
2
3
4
5
6
7
cd /var/www/example_com/
sudo hg add
sudo hg commit -m "initialer Commit"

cd /var/www/example_net/
sudo hg add
sudo hg commit -m "initialer Commit"

Um nun zu prüfen, ob sich einer der Ordner geändert hat, habe ich mir ein kleines PHP-Script geschrieben und in "/var/check/check.phs" abgelegt. Es geht die in $SOURCEDIRS abgelegten Ordner durch, prüft, ob sich darin Dateien geändert haben und zählt, wieviele Änderungen existieren. Die Anzahl der Änderungen werden zusammen mit dem aktuellen Datum und der aktuellen Uhrzeit in die Datei $CHECKFILE geschrieben:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<?php
  $CHECKCMD   = "hg status -R";
  $CHECKDATE  = date("Ymd-Gis");
  $CHECKFILE  = "/var/check/check.txt";
  $SOURCEDIRS = array("/var/www/example_com/",
                      "/var/www/example_net/");

  $output = array();
  $status = 0;
  try {
    foreach ($SOURCEDIRS as $sourcedir) {
      exec($CHECKCMD . " " . escapeshellcmd($sourcedir), $output);

      if (0 < count($output)) {
        print($sourcedir . "\n");

        $status = $status + count($output);

        $output = array();
      }
    }
  } catch (Exception $e) {
    $status = "error";
  }

  file_put_contents($CHECKFILE, $CHECKDATE . " = ". $status);
?>

In meinem persönlichen Fall habe ich es so gemacht, dass die Prüfdatei wiederum per Webbrowser abrufbar ist. So kann ich auch unterwegs relativ schnell den Status überprüfen. Man könnte auch hergehen und bei Abweichungen eine E-Mail versenden. Dafür muss am Ende des Scripts einfach nur geguckt werden, ob "(0 !== $status)" ist.

Um nun regelmäßig zu prüfen, ob eine Änderung stattgefunden hat, kann man das Script (z.B. stündlich) via Cron aufrufen lassen. Natürlich kann man es auch zwischendurch händisch aufrufen, falls man das Verlangen danach hat. Folgende Zeile kann man in seine "/etc/crontab" schreiben:

1
0 * * * * root php /var/check/check.phs >/dev/null 2>&1

So schnell hat man mit einfachen Mitteln eine kleine Serverüberwachung implementiert. Frei Haus bekommt man obendrein eine Versionsverwaltung seiner Webseite geschenkt. Diese kann sich vor allem bei kleineren Webseiten als durchaus nützlich erweisen. Man sollte das ganze jedoch nicht ausschließlich anstelle eines regelmäßigen, ordentlichen Backups verwenden. :)

Überwachende Grüße, Kenny

Seite 1 von 77123...Letzte »