Der Friede der Wellen des Meeres – sei dein
Der Friede der leuchtenden Sterne – sei dein
Der Friede des Fließens der Lüfte – sei dein
Der Friede der nächtlichen Sterne – sei dein
Der Friede der ruhigen Erde – sei dein
Mögen der Mond und die Sterne dir immer leuchten

In den letzten Jahren ist es ruhiger geworden, viel ruhiger. Vielleicht weil ich das Thema Blog überlebt hat, vielleicht weil es weniger zu sagen gibt, vielleicht auch weil das Internet ein Ort geworden ist der viel lauter, viel greller, viel bewertender geworden ist als noch vor 10 Jahren.
Vielleicht auch weil es persönlich eine Zeit des Umbruchs, der Orientierung und Weichenstellung zu sein scheint.

Mit dieser Nachdenklichkeit und in diesem Sinne:
Prost auf die letzten 10 Jahre,
Prost auf all die Geschichten die sie brachten,
Prost auf die Zukunft
und auf alles was sie bereithalten mag!

Download newest Version

hinter diesem Namen verbirgt sich gerade eine kleines absolut süchtig machendes Spiel.
Es geht dabei darum auf dem Spielfeld auftauchende Zahlen zu verschieben.
Gleiche Zahlen vereinigen sich zu ihrer Summe.
Ziel des Spiels ist es ein Feld mit der Zahl 2048 zu erreichen.

Aber ich schäzte es ist fast schwerer erklärt als einfach Ausprobiert:
Ich habe hier mal eine kleine Version zum Antsten eingebunden,
einfach auf Start klicken und mit den Pfeiltasten losschieben

Start

Wer spaß daran gewonnen hat, unter all the 2048 findet sich eine Liste aller möglichen variationen der Spielidee.

Zu der hier eingebunden Version bleibt zu sagen das der Hauptteil des Codes nicht von mir sondern ist im wesentlich von Johan Nordberg. Nähres hier: js1k.

Ich bastele gerne mal und probiere dabei Dinge aus,
einfach weils geht. Wie der Zufall so will war heute dieser Blog dran. Ich hatte bereits vorher hin und wieder an Optimierungen geschraubt, dabei allerdings immer auf Datenspaarsamkeit und ähnliches geachtet.
Google Analytics kam daher z.B. bisher nicht in Frage. [Ja das ist einfach ein bischen meine Macke]

Umso mehr verwunderte es mich, als ich dann heute feststellte das dieser, mein eigener Blog, Skripte von Google nach lud. Und das gleich garnicht zu knapp: Ganze neun Scripte wurden bei einem Seitenaufruf von ajax.googleapis.com geladen. Der Sache musste also nachgegangen werden. Drehte vielleicht eines der Pluings frei, war in einem der letzten Updates eine entsprechende Änderung gewesen oder am schlimmsten gar war es eventuell jemandem gelungen Code bei mir einzuschläusen ?

Die Google-Suche war leider wenig erfolgreich. Lediglich einige Blogposts die beschrieben wie man all seine Scripte von Google läd tauchten auf, und das war ja nun genau das gegenteil von dem was ich suchte. Da das nun also nicht half war der nächste logische Schritt mal zu schauen wo diese Einbindung den eigentlich stattfindet. Also Shell aufgemacht, und die WordPressfiles nach “ajax.googleapis.com” durchsucht. Das Ergebnis deutete Relativ eindeutig auf “wp-includes/script-loader.php”. Hier werden scheinbar diverese “scriptaculous” Scripte aus den googleapis eingebunden.
Na das war zumindest schon mal konkreter. “wp-includes/script-loader.php” ist aber kein File eines Plugins, dass ist ein File des WordPress-Cores. Also nochmal schnell in die Suchmaske, und siehe da unter “Removed from Core” tatsächlich wurde in Version 3.5 diverse Scriptaculous-Scripte von “Mitgeliefert” auf die “Google-Version” umgestellt. WordPress-Core,umgestellt, dann müssten ja andere das “selbe Problem” haben, so dachte ich. Nun gut, schnell in ein-zwei WordPressblogs befreundeter Nerds aufrufen. Aber hier war keine Spur von “ajax.googleapis.com”.
Also doch mal genauer schauen wie das mit diesen Javascript libs in WordPress funktioniert.

Wenig später war dann auch die Sachlage klar und der “Schuldige” gefunden:
Wordpress hat ganz grob gesagt, einen Mechanismus der scheinbar verhindert das Scripte mehrfach eingebunden werden. Daher wird ein Script registriert (das passiert für die googleapi Scripte in der “script-loader” Datei). Wird das Script anschließend benötigt wird eine Funktion aufgerufen (bei den Scriptaculous-Scripten war es bei mir das Lightbox-Plugin) die dann dafür sorgt, das das Script eben genau nur ein mal eingebunden wird.
Sprich der eine Schuldige sind eigentlich zwei. Wobei das Lightbox-Plugin nicht wirklich was dafür kann, denn bei dessen letztem Update lieferte WordPress die entsprechenden Scripte noch frei Haus mit.

Abschließend ein etwas unschönes Problem, vor allem da mir kein schöner Lösungsweg klar ist.
Natürlich kann ich das Lightbox-Plugin deaktivieren, aber das kann ja nicht die Idee sein.
Ich kann natürlich auch in dem script-loader File die Locationen der Scriptaculous-Scripte von Googleapis auf meine Domain biegen, aber das ist nicht nur extrem unschön sondern geht auch bei jedem Update flöten.

Immer am Meer entlang, immer das Wasser im blick, von Ort zu Ort.
Unterbrochen hin und wieder von Pausen, zum essen fassen, oder weil der Regen gar zu unangenehm war.

Vorraussetzungen – Was wird benötigt:

einen Webspace, mit PHP.
PHP braucht PDO und sqlite Support.
(sollte ich hier was vergessen haben bitte kommentieren)

Die Files:

Als erstes mal müssen die Datein geladen werden:

wget https://www.dataharbour.de/FSyncMS.tar.gz

(alternativ einfach hier runterladen)
Danach das Archiv entpacken

tar xvzf FSyncMS.tar.gz

dabei sollte ein Ordner mit (vorallem) folgenden Dateien dabei herrauskommen:

index.php
user.php
weave_storage.php
settings.php
weave_basic_object.php
weave_utils.php

Verändert werden muss nachher eigentlich nur die settings.php, aber zu erst optional Webserver einstellungen.

(optional) Die Url – der Webserver

Dieser Schritt ist optional, wenn kein Zugang zur Webserverconfig besteht kann man dies auch weglassen.
Ziel ist es die Url zu maskieren,
in lighttpd geht dies z.B. mit folgendem Statement
(vorrausgesetzt das der Ordner in dem die Dateien liegen fsync heißt) :

url.rewrite = ( "^/fsync/(.*)$" => "/fsync/index.php/$1")

bei Apache geht das mit

Alias /fsync /fsync/index.php/

Die Settings

Nachdem die Grundvorrausetzungen geschaffen sind, auf zur Settings.php:
Hier gibt es eigentlich nur zwei Einstellungen,
die URL zu dieser Installation und ob die Registrierung freigeschaltet ist oder nicht.
Also ENABLE_REGISTER auf TRUE

define("ENABLE_REGISTER", true);

und FSYNCMS_ROOT auf die URL

define("FSYNCMS_ROOT","https://www.example.com/fsyncms/");

Wichtig sind bei der URL 2 Dinge:

• Die Url muss mit einem / abschließen.

• Wenn man keinen Alias angelegt hat, dann muss hier als URL die URL zur Index Datei angegeben werden (und auch mit einem / beendet). Bsp.: https://www.example.com/fsyncms/index.php/

danach speichern und schließen.

Der Account

Als nächstes zum Client und einen Account erstellen.
Im Firefox unter Extras -> Synchronisation einrichten anklicken.
Danach im neuen Fenster auf Neues Benutzerkonto anlegen.
Daten eingeben,
und bei Server, eigenen Server auswählen, und URL eintippen (ist die selbe wie jene die in den settings steht).
2 oder 3 mal auf weiter klicken und fertig :)

Sync sollte jetzt funktionieren,
und zwar mit Firefox 4 , Firefox 5 und Firefox 6.
Optional würde ich noch empfehlen die registrierung in der settings.php zu deaktivieren wenn man sie nicht benötigt, um nicht jedem ablageplatz anzubieten.

der HTTPs Finder ergänzt jetzt dieses Verhalten, in dem er neben dem Surfen testet, ob die Aufgerufende Seite auch per HTTPS erreichbar ist.
Ist das der Fall so meldet das Plugin dies mit einer Statusleiste am oberen Ende des Fensters.
Zudem ermöglicht das Plugin gleich eine Regel für HTTPS everywhere anzulegen, so das in Zukunft immer direkt HTTPS verwendet wird.

Der erste Schritt auf diesem Weg, war die Pakete des Users zu markieren.
Dazu ist das Kernelmodul ipt_owner nötig,
welches mit modprobe ipt_owner geladen wird.

Danach können Iptables Regeln verwendet werden die auf User matchen, was wir gleich benutzen:

sudo iptables -t mangle -A OUTPUT -m owner --uid-owner $USERNAME -j MARK --set-mark 1

$USERNAME ist natürlich durch den Namen des Users zu ersetzen, dessen Traffic umgeleitet werden soll.
So, nun werden schon mal alle Pakete des Users markiert,
als nächstes bereiten wir eine zweite Routingtabelle für jene Pakete vor:

sudo echo "1 special" >> /etc/iproute2/rt_tables

Damit wird ein zusätzliche Routingtable mit Name special angelegt.
Als nächstes schieben wir alle Pakete die Markiert wurden eben in jenen Routingtabelle

sudo ip rule add from all fwmark 1 table special

Soweit so gut, wir haben die Pakete separiert, und können separate Routen für diese definieren.
Da wir derzeit noch eine Routen definiert haben, sollte der Traffic allerdings noch normal fließen.
Bevor wir das ändern, legen wir jedoch zuerst eine NAT-Translation fest.
Dies sorgt dafür, das die Absende-IP ausgetauscht wird (Ich weiß nicht ob dies immer nötig ist, bei mir enthielten die Pakete allerdings fälschlicher weise die Absende IP von eth0).

sudo iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Damit sollten jetzt die per ppp0 ausgehenden Pakete auch die richtige absende IP haben.
Also sorgen wir nun auch dafür das unsere Pakete über ppp0 ausgehen:

sudo ip route add default dev ppp0 table special

Tada :) sollte funktionieren.

Besonderheiten

Es kann sein, das DNS, sprich die Namensauflösung nicht mehr funktioniert, sofern der per DHCP reingepushte DNS server im Lokalen Lan steht, was nun nicht mehr erreichbar ist.
Um dies zu ändern kann man einfach in die Tabelle folgenden eintrag hinzufügen:

sudo ip route add throw 192.168.1.0/24 table special

Wobei die IP durch jene des lokalen Netzes zu ersetzen ist.

Ein weiteres mögliches Problem der Konfiguration liegt im Tunnel,
bricht dieser (warum auch immer) weg, sprich das interface geht down, wird die Route automatisch aus dem Table entfernt, sprich es existiert keine Defaultroute mehr, sprich der Traffic wird wieder normal geroutet.
Manchmal mag dies praktisch sein, in manchen fällen will man jedoch das der Traffic in einem solchen fall lieber garnicht fließt.
Um das zu erreichen bietet es sich an 2 Scripte zu erstellen:
Zu erst einmal in /etc/ppp/ip-up.d/ , zum beispiel default_special:

#!/bin/sh
`ip route del default table special`
`ip route add default dev ppp0 table special`

Und zum anderen in /etc/ppp/ip-down.d/, zum beispiel default_special:

#!/bin/bash
`ip route del default table special`
`ip route add blackhole default table special`

Diese Scripte sorgen dafür, dass wenn der ppp0 aufgeht, die diefaultroute eingetragen wird.
Und wenn der Tunnel wegbricht, eine ‘blackhole’ route eingetragen wird, die dafür sorgt, das die Pakete einfach verworfen werden.

Zubereitung

Alles in einen Topf, dann Rühren :P ,
bis der Teig schön glatt ist.
Nun ca. 30 Min gehen lassen.
Danach ausrollen, nach Wunsch belegen und in den Ofen schieben.

Benötigte Zutaten

500 g Mehl

gerne zwei Sorten wie z.B. 200g Weizenmehl und 300g Weizenvollkorn Mehl
schmeckt aber auch mit nur einer Sorte Mehl

1,5 Teelöffel – 1 Esslöffel Salz

400ml warmes Wasser

12 g frische Hefe oder 1 Tütchen Trockenhefe

optional noch Sonnenblumenkerne / Kürbiskerne und Haferflocken zum verfeinern des Teigs

Mach-Anleitung

Mehl, Salz (und sofern Trockenhefe benutzt wird auch diese)  in eine Schlüssel geben und gut mischen.
Nach eigenen vorlieben, Sonnenblumenkerne / Kürbiskerne und Haferflocken einmischen.
Das Wasser und, sofern nicht schon geschehen, die Hefe beimischen.
Den Teig gut durchkneten (ca. 5 min).

Folgend, die Teigschüssel abdecken und den Teig ca. 40 Minuten bei Raumtemperatur gehen lassen.

Im Anschluss, den Teig in eine gefettete Form geben.
Nach eigenen vorlieben mit Sonnenblumen/ Kürbiskernen oder ähnlichem Bestreuen.
Nun den Teig bei 200 Grad für ca. 40 Minuten backen.

Zum Schluss, das frische Brot genießen :)

Fazit

Wenn man knapp 2 Stunden zu Hause ist, und lust auf frisches Brot hat, kann man dies schnell und einfach Selberbacken. Die benötigten Zutaten kosten zusammen keine 50 Cent, und der Duft eines Brots im Ofen macht alleine bereits Appetit.

In diesem Sinne Guten Appetit :)