onli blogging

Lichter für Fahrräder sind doof. Entweder kostet der Dynamo Kraft beim Fahren, oder man muss sich mit Akkus oder gar Batterien rumschlagen, und muss die Lampen jedes mal an- und abstecken, sonst werden sie gestohlen.

Deswegen finde ich das Prinzip der Induktionslichter gut, die ich bisher aber nur bei Reelight gesehen habe. Der Magnet und die Lampen werden fest montiert, danach ist nur das geringe zulässige Gewicht ein Manko und weder Batterien noch Dynamo am Fahrrad.

Mir war wichtig, keine Blinklichter zu haben. Mag man eher wahrnehmen, aber ich finde sie total irritierend. Deswegen wählte ich das SL 150, es leuchtet durchgängig.

Die Montage war gar nicht mal so einfach, ich stellte mich aber auch ein bisschen doof an. Die Magneten in die Speichen schrauben, die Lampen mit der Reifenschraube festklemmen. Bei mir waren die Magneten etwas frickelig und ich habe nicht gleich gerafft, dass das Rücklicht sehr wohl in die richtige Richtung verstellbar ist, anfangs war es zu weit vom Magnet weg. Das Video zeigt die Montage ganz gut:

Am Ende sind es dann zwei wirklich kleine Lichter. Ich habe sie noch nicht bei Nacht getestet, aber mir scheint, dass sie wirklich nur die eigene Sichtbarkeit etwas erhöhen - den Weg werden sie kaum beleuchten. Behaupten sie aber auch gar nicht, und so wäre das auch ok für mich.

Anlass war natürlich mein momentanes Projekt, ich brauchte einen Weg, vom Server aus den Browser über Updates der Feeds zu benachrichtigen. Dafür soll der Browser nicht alle paar Sekunden beim Server anfragen, der Server soll von sich aus den Browser benachrichtigen. Und genau das geht mit Websockets.

Auf Javascriptseite wird ein neuer Websocket erstellt, dann kann über seine Funktionen auf die Nachrichten vom Server reagiert werden:

var socket = new WebSocket('ws://' + location.host + '/updated' );

socket.onopen = function() {
    socket.send('erste nachricht an den server');
}

socket.onmessage = function(msg){
    console.log(msg);
}

Ein reales Beispiel findet sich hier.

Auf der Serverseite läuft bei mir Ruby mit Sinatra, und der Rack-Server ist puma. Ich habe nach einer Kollision damit in einem anderen Projekt gerne etwas Distanz zu EventMachine. Und es gibt auch ein passendes Gem, mit dem selbst bei diesem etwas seltenem Setup Websockets schnell funktionieren: sinatra-hijacker. Mein Beispielcode:

require 'sinatra'
require 'sinatra/hijacker'
register Sinatra::Hijacker

websockets = []

websocket '/updated' do
    websockets << ws
    ws.onmessage  do |msg| 
        puts msg
    end
    ws.onclose do
        websockets.delete(ws)
    end
    "Done"
end

Ein reales Beispiel findet sich hier.

Funktionierte am Ende erstaunlich gut. Ich muss mich allerdings noch an dieses neue Werkzeug gewöhnen. So übertrage ich bis jetzt damit nur Benachrichtigungen und hole die neuen Elemente dann per Ajax, das ist eigentlich nicht nötig, es ginge sicher auch direkt. Und ich brauchte ein bisschen um zu realisieren, dass es nicht mehr als ein Websocket pro Verbindung braucht, wenn man verschiedene Events per JSON unterscheidbar macht.

Ich habe heute meinen Feedreader auf github gepusht. Frische Alpha-Software, das momentane Ziel ist, ihn zu einem vollwertigen Digg-Reader Ersatz zu machen, meinen jetzigen Feedreader. Also bin ich absolut noch nicht fertig.

Aber er kann schon ein bisschen was. Feeds können abonniert werden, Einträge werden angezeigt und beim Scrollen als gelesen markiert, Blog-Updates kommen an.

Je nachdem wo man anfängt hat dieser Feedreader eine lange Geschichte oder ist zwei Tage alt. Vor einigen Jahren stolperte ich über pubsubhubbub und wollte das für Serendipity. Ich war und bin kein Gläubiger des damaligen realtime-Hypes, glaubte aber doch und immer noch, dass einige nette Dinge mit solchen Mechanismen umgesetzt werden können. Und es war einfach völlig einleuchtend für mich, wieviel effektiver es sein muss, wenn Blogs bei Updates den Reader anpingen und nicht der Reader alle 5 Minuten den Feed herunterladen muss.
Wie auch immer, ich scheiterte damals daran das ordentlich umzusetzen, aber es blieb in meinem Hinterkopf.

Ein ganzes Stück später versuchte ich mich nochmal daran, zweimal sogar, und diesmal funktionierte es. Zum einen implementierte ich es in dsnblog auf Blogseite. Und - wichtiger noch - daraufhin in rsspusher als Hubclient. Was fehlte war das User-Frontend, eben der Feedreader den ich nun gebaut habe.
Entsprechend der Hintergrundgeschichte hat feedtragón eine Besonderheit: Im Gegensatz zu tt-rss und anderen selbstgehosteten Readern betreibt er kein Polling. Updates der abonnierten Blogs werden zum Reader gepusht, dieser soll sie nur anzeigen und den externen Dienst notdürftig verwalten.

Das erspart, mit einem poll-daemon den Server unnötig zu belasten, für den kleinen Preis der Erreichbarkeit von außen. Derzeit übernimmt superfeedr diese Aufgabe, 10000 kostenlose Benachrichtigungen sollten völlig ausreichen und die Rack-Middleware funktioniert hervorragend. Sollte das doch mal ein Problem werden, steht mit rsspusher eine (solange viel zu arbeitsintensive) Alternative bereit.

Ich werde den Reader auf jeden Fall für mich vervollständigen. Wer helfen will sei eingeladen.

Das Herumhantieren mit dem DNS-Server für cloudflare und der Hinweis zu DANE hat mich daran erinnert, dass ich vor einiger Zeit mal einen lokalen Cache für DNS-Anfragen haben wollte. Nach dieser Anleitung ist das mit dnsmasq auch nicht zu schwierig.

Zuerst installieren:

sudo apt-get install dnsmasq

Dann muss die /etc/dnsmasq.conf bearbeitet werden, um Anfragen nur vom eigenen PC zu erlauben:

listen-address=127.0.0.1

Außerdem soll dnsmasq nur DNS anbieten, also:

no-dhcp-interface=eth2

eth2 entsprechend anpassen.

In der /etc/dhcp3/dhclient.conf dann noch diese Zeile einkommentieren:

prepend domain-name-servers 127.0.0.1;

Ich war mir nicht sicher, ob wicd die /etc/resolv.conf in Ruhe lässt. Daher habe ich in dessen Konfiguration für die Kabelverbindung ebenfalls die DNS-Server eingetragen, mit 127.0.0.1 als ersten Server.

Schließlich noch dnsmasq neustarten und es sollte laufen:

sudo service dnsmasq restart

Ob es wirklich funktioniert, kann man mit dig testen:

onli@Fallout:~$ dig www.google.de

; <<>> DiG 9.9.5-3-Ubuntu <<>> www.google.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11671
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.de.			IN	A

;; ANSWER SECTION:
www.google.de.		288	IN	A	74.125.230.248
www.google.de.		288	IN	A	74.125.230.247

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Oct 08 17:14:49 CEST 2014
;; MSG SIZE  rcvd: 63

Ich hatte das vorher mit dem Paket dnscache-run versucht, was aber leider kaputt ist - zumindest bekam ich es nicht zum Laufen.

Jetzt ist es durch, hier läuft Cloudflare. Die Umstellung lief leider nicht reibungslos. Das ist aber nur teilweise Cloudflares Schuld.

DNS-Server wechseln schwierig

Cloudflare funktioniert durch Auswechseln des DNS-Servers. Den bei hosteurope im fürchterlichen KIS zu ändern ist nicht einfach. Es muss an den Support eine Mail geschrieben werden, um die Domain auf "Als Reseller verwalten" zu stellen und schließlich den DNS-Server wechseln zu dürfen. Die Info fand ich nur per Google.

SSL aktiviert, aber Zertifikat nicht da

Bei der Einrichtung von Cloudflare konnte man zwar SSL aktivieren. Aber als die Umstellung erfolgt war, war das Zertifikat für die Domain noch nicht da, nur Cloudflares generisches wurde ausgeliefert. Browser zeigten also eine Fehlermeldung.

Ich habe dann die Weiterleitung auf https deaktiviert und in den Optionen der Domain Full SSL (Strict) aktiviert, und Cloudflare Zeit gegeben. Eben schaue ich in die Optionen und sehe, dass die Option auf Flexible SSL umgestellt wurde (das war die unsichere Variante). Da stimmt etwas immer noch nicht, ausgerechnet bei der ausschlaggebenden Funktion.

Edit: Auf strict Full SSL gewechselt und sofort eine Bestätigung bekommen, und die Seite steht auch noch. Vielleicht war es das jetzt.

htaccess musste angepasst werden

Per .htaccess hatte ich hier https festgeschrieben, aber für die Feeds deaktiviert. Diese Regel funktionierte nicht mehr, da

RewriteCond %{HTTPS} off

nicht erkannt wurde - was natürlich am umgewollten Flexible SSL liegen kann. Trotzdem, für Cloudflare funktionierte

RewriteCond %{HTTP:CF-Visitor} '"scheme":"http"'

und die ganze .htaccess sieht nun so aus:

#RewriteCond %{HTTPS} off
RewriteCond %{HTTP:CF-Visitor} '"scheme":"http"'
RewriteCond %{QUERY_STRING} !^.*/feeds/.* 
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI}

#RewriteCond %{HTTPS} on
RewriteCond %{HTTP:CF-Visitor} '"scheme":"https"'
RewriteCond %{QUERY_STRING} ^.*/feeds/.*
RewriteRule .* http://%{HTTP_HOST}%{REQUEST_URI}

RewriteCond %{HTTP_HOST} !^$
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteCond %{HTTPS}s ^on(s)|
RewriteRule ^ http%1://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Edit: Ja, mit Full SSL funktioniert wie erwartet auch die alte RewriteCond wieder.

Performance besser? Schwer zu sagen

Hat sich der Aufwand gelohnt? Ich bin noch nicht sicher. Pingdoms Ping zufolge ist die Antwortzeit besser geworden:

Das kann aber auch an der ausgesetzten Weiterleitung zur https-Version liegen.