Ein beliebtes Ritual auf Urlaubsreisen ist die Verkostung dort einheimischer Speisen, Getränke und Spirituosen. So stieß ich im letzten Urlaub auf den Macaronesian White Gin, der auf den Makaronesischen Inseln destilliert wird. Der Gin kommt, etwas genauer, aus San Miguel de Abona auf Teneriffa.

Die Kanarischen Inseln sind bekannt für ihr sehr warmes und in Teilen gleichzeitig niederschlagsreiches Klima — ideale Bedingungen für Vegetation und Gin-Botanicals.

Dass es sich beim Macaronesian White Gin um einen lokalen Gin handelt, wird schon an der Flasche deutlich. Statt aus Glas ist diese aus gebranntem weißem Ton. Auch das für den Gin verwendete Wasser kommt laut der Produkt-Website von der Insel. Es zeichnet sich angeblich durch seine vulkanische Filtration und Weichheit aus.

Auf Seite der Botanicals wartet der Mittelmeer-Gin mit Wacholder, Kardamom, Engelwurz, Süßholz, Zitronenschalen, Orangenschalen und »anderen pflanzliche Stoffe in Top-Qualität« auf. Woher diese Stoffe kommen, lässt sich leider nicht heraus finden.

Der Gin ist im deutschen Sprachraum leider noch recht unbekannt — es finden sich kaum Berichte oder Rezensionen über den Gin. Sei’s drum; dann machen wir diesen Gin eben etwas bekannter. :-)

In der Nase spielt der Gin unvergleichlich leicht auf. Es findet sich kaum ein Anklang von strengem Alkoholdurft, stattdessen umwirbeln Aromen von Minze und Citrus die Nase. Die Erinnerung an die frische Meeresbrise ist definitiv gelungen und wahrnehmbar.

Im Mund spielt der Gin ebenfalls sehr leicht auf, man traut ihm kaum die Vierzig Prozent Alkohol zu, so leicht schmeckt er. Allerdings ist die Komplexität hier deutlich geringer, als es wünschenswert wäre. Vornehmlich sind hier Minze, Zitrus und ein Hauch Wacholder neben subtilen floralen Noten zu schmecken. Ein langer Nachhall von frischen Orangen, Zimt und Lakritze bleibt nach dem Geschmack auf der Zunge. Die Qualität des Gins ist zweifelsfrei, der Geschmack sehr leicht und ausgeprägt, wenn auch nicht von sehr großer Komplexität. Mediterraner Sommer im Glas eben.

Der Macaronesian White Gin hat 40% Alkohol und kommt in der 0,7l-Flasche. Er kostet (etwa bei Uvinum ca 28 Euro, ist aber auf den Kanaren deutlich(!) günstiger zu bekommen, circa 16-18 Euro dort.

Ganz nahe meiner Heimat hat sich still und heimlich eine kleine Gin-Manufaktur empor gearbeitet, deren Produkt wohl einer weiteren Würdigung bedarf.

Dem an der Saar destillieren Gin sieht man sofort seine Herkunft aus einem traditionellen Wein-Anbaugebiet an. Der Zusatz »Schiefer–Riesling Infused« verrät auch dem Letzten das Geheimnis. Dieser Gin wurde aus dem Wein geboren, und dementsprechend aufwändig ist die Gestaltung des Etiketts und der Verpackung. Die mit Blindprägung versehenen Flaschen-Gesicher transportieren eine konservativ-wertstabile Botschaft nach außen, die Flasche ist zudem mit einem Jahrgangs-Korken verschlossen — in meiner Sammlung soweit einzigartig; der Wein sagt andauernd »Hallo«. Das verwendete extravagante Verpackungspapier und der Wachsstopfen tun ihr übriges, um die Einzigartigkeit des Gins zu unterstreichen.

Ebenfalls ist auf dem Etikett die Batch-Nummer und der verwendete Infusions-Riesling angegeben. Ich kann mich glücklich schätzen, eine Flasche aus der erstem Rutsche erwischt zu haben.

Über dreißig regionale Botanicals verleihen dem Gin seinen Geschmack und auf der eigenen Website ist man um größtmögliche Authentizität und Bontanical-Harmonie bedacht. Die volle Auflistung der dreißig Zutaten bleiben uns die Saar-Destiller schuldig, preisgegeben werden immerhin Schlehe, Hagebutte, Angelika, Hopfenblüte, Weinrose, Mandelschale, Koriander, Zimt und Ingwer. Wer hier noch etwas weiter rätseln will, kann das Botanical-Periodensystem auf der Homepage gerne studieren und Zutaten an mich weiter geben. Außerdem erhält jede Flasche einen Spritzer des VDP Schiefer-Rieslings, mit welchem der Gin »dampfinfundiert« wird.

Wie aus der Vielzahl der Botanicals eigentlich auch nicht anders zu erwartet, bietet der Gin schon in der Nase ein umfassend komplexes Bouquet an Aromen, Anspielungen und Möglichkeiten. Aromen von reifen Früchten, Trauben, holzige florale Noten, Zimt und ein minimaler Alkoholgeruch machen Lust auf mehr.

Beim Verkosten zeigt sich dann, dass diese Vielfalt auch im Mund bestehen bleiben kann. Prägnanter Wacholder und eine durchaus angenehme trockene Strenge lenken den Geschmack sehr in die London-Dry-Richtung, stehen aber den übrigen Nuancen nicht im Weg. Auch hier kann und will sich der Gin nicht von seinen Wurzeln verstecken, die Mineralität und leichte Säure eines trockenen Weins sind deutlich zu schmecken: Die Weinbeigabe adelt den Gin und rundet den Geschmack sehr weich ab. Dabei ist der Wein nie aufdringlich oder vordergründig.

Im Nachhall bleibt viel frische ätherische Minze, etwas Zitrus und ein Hauch von weicher Lakritze lange im Gaumen. Ein außergewöhnlicher Genuss.

Ferdinand’s Saar Dry Gin hat 44% Alkohol und wird in der 0,5-Liter-Flasche verkauft. Er kostet ca 35 Euro, etwa bei Amazon.

Gestern hat Apple die Apple Watch vorgestellt, die lange erwartete Smartwatch des Herstellers. Apple dringt damit endgültig in Luxus-Sphären vor. Waren die Aufpreise bei den Telefonen vorher schon recht happig, kommt man bei der Apple Watch nicht umhin, wirklich zwei Mal hinzusehen, ob die Preise wirklich echt sind. Doch der Reihe nach.

Um die Funktionen und das Design der Uhr soll es hier gar nicht gehen; Infos dazu kann man zur Zeit an jeder Ecke nachlesen. Ich möchte mich mit den Preisen für die Uhren auseinander setzen.

Die im vergangenen Herbst erstmalig präsentierte Uhr ist in drei Modellen mit jeweils zwei Größen zu haben: Apple Watch Sport, Apple Watch und Apple Watch Edition. So weit, so bekannt.
Wirklich neu bei der Apple Watch ist die Diversifikation über verschiedene Materialien und das (unverzichtbare) Zubehör, die Armbänder. Darüber hinaus gibt es von der Apple-Uhr so viele Varianten wie von keinem anderen Apple-Produkt vorher: Insgesamt 38 Varianten lassen sich vorbestellen. War es bei anderen Apple-Produkten bisher so, dass diese sich durch Leistungsfähigkeit (Rechner: Mehr RAM, schnellere CPU, besseres Display, größere SSD) oder den reinen Speicher (iPad, iPhone, iPod) oder eines dieser Merkmale in Kombination mit der Größe (Rechner, iPad, iPhone, iPod) unterschieden haben, ist dies bei der Watch kaum noch mehr der Fall. Die Preisunterschiede für die zwei Größen der Uhr sind durchweg fast schon vernachlässigbar, liegen sie doch stets nur bei 50€. Die Funktionalität ist jedoch bei allen Uhren exakt gleich, es gibt keinen Unterschied bei Funktionen, Speicher, Akkulaufzeit oder dergleichen: Ob die Uhr nun 399€ oder 17.000€ kostet: Sie kann das Gleiche und sieht ähnlich aus.

Nun sind hohe Preise bei Armbanduhren von jeher kein Kauf-Hindernis, ganz im Gegenteil. Man kann auch leicht 17.000€ für eine Uhr eines beispielsweise deutschen oder Schweizer Herstellers ausgeben; überhaupt kein Problem. Die Liste der möglichen Hersteller hier ist lang: IWC, Rolex, Patek Philippe, A. Lange und Söhne, Nomos Glashütte, Vacheron Constantin, … um nur einige zu nennen. Hier findet man etwas für jeden Geschmack bei entsprechendem Geldbeutel. Und 17.000€ sind hier für einige dieser Hersteller eine eher günstige Messgröße. Insofern zieht das plumpe Argument des überteuerten Preises, welches einige Kritiker vorbringen, bei der Watch nicht. Man kauft sich keine teure Uhr, um die Zeit darauf ablesen zu können; die gibt es billig an jeder Ecke. Zudem bekommt man auch um den Preis von einhundert Euro eine Uhr mit Funk und Solar, die ebenfalls in 10 Jahren noch funktionieren wird, die immer genau und der nie der Saft ausgehen wird.
Für einen hohen Preis bekommt man also rein rational keine sehr genaue, funktionale oder robuste Uhr. Man gibt also das Zehn- bis Hundertfache für die Luxusausführung einer Ware aus, die nüchtern gesehen nicht mehr kann als eine günstige. Warum kauft man sich denn dann überhaupt eine solch teure Uhr?

Man kauft Sie sich als Schmuckstück, als etwas, was man sich verdient hat und möchte Sie möglichst lange tragen und vielleicht sogar weiter geben. Idealerweise bekommt man sie vielleicht sogar geschenkt. Im besten Fall verliert die Uhr über lange Jahre nicht an Wert, sondern steigt sogar. Warum? Weil teure Manufaktur-Uhren einzigartige Kombinationen aus handwerklichem Können und oft zeitlosem Design sind und in der Regel ein Automatikwerk haben, bei dem man jede verbaute Komponente auch noch in 20 Jahren wird warten und tauschen können. In diesen Uhren stecken viele Stunden handwerklicher Arbeit und der Preis steigt mit der Anzahl der Komplikationen, der Fertigung und Veredelung, die einer Uhr zuteil werden.

Genau hier sehe ich ein Problem: Bei der Apple Watch ist der fürstliche Aufpreis des Edition-Modells nur gering vom Materialwert, etwaigen Komplikationen, inneren Werten oder Finishing abgedeckt: Das Innenleben der Uhr ist ja das Gleiche und auch rein elektronisch. Sicher, das Gold ist teuer und auch die Armbänder werden müssen eine entsprechende Qualität haben. Aber rein technisch wird die Uhr trotzdem in ein bis zwei Jahren obsolet sein. Dazu kommt, dass die erste Generation von Apple-Technik in der Regel noch schneller obsolet als die nachfolgenden wird.

Um das festzustellen, muss man kein Technik-Experte sein. Die Produktlebenszyklen sind zwar je nach Gerät etwas unterschiedlich, aber alleine schon aus dem Grund, dass die Apple Watch nur mit einem iPhone funktionieren wird, kann geschlossen werden, dass beide halbwegs aktuell gehalten werden wollen.

Mit der Rationalität in Sachen Preis hört es übrigens auch schnell wieder beim Aufpreis von 7.000€ (11.000€ zu 18.000€)für ein anderes Armband, welches es natürlich auch nicht einzeln zu kaufen gibt, auf. Das ist schlicht nicht mehr verargumentierbar, sondern pures Status- und Luxusgehabe. Wenn man nicht mehr weiß, wohin mit seinem Geld, kauft man sich eben die teuerste Apple Watch mit dem teuersten Armband. Total egal, was sie kostet und wie hoch der Aufpreis ist: Ich habe Sie, du nicht. Ätsch. Get Rich or die tryin.

In eine ähnliche Kerbe schlagen teilweise auch die Preise für die Armbänder. Während sehr hochwertige Shell-Cordovan-Leder-Armbänder für Uhren der Marke Nomos um die 60 Euro kosten, will Apple für ein modernes Lederarmband 269 Euro und für Gliederarband aus Metall 499 Euro sehen. Das elegante Milanaise-Band ist da für 169 Euro fast ein Schnäppchen. Man kann nur hoffen, dass sich die Bänder auch an zukünftigen Generationen der Uhr werden befestigen lassen.

Um sich aus dem Dilemma des puren Luxus-Aufpreises zu befreien, könnte Apple bei der nächsten Iteration einen Austausch- oder Upgrade-Service für die Uhren anbieten: Für, sagen wir, 300 Euro bekommt jeder Käufer einer Apple Watch oder Apple Watch Edition dann das neueste technische Innenleben in seine Uhr verpflanzt. Für die günstige Apple Watch Sport gilt das natürlich nicht bzw ist es unattraktiv. Im Pricing ist Apple ja schon immer Weltklasse gewesen. Mit dem Upgrade würde Apple auch die Early Adopter bei der Stange halten.

Möchte man allerdings pokern, könnte sich der Kauf der teuersten Apple Watch vielleicht doch lohnen, aber nur, wenn man sie für längere Zeit verschweißt und ungetragen im Schrank liegen lässt: Bei eBay erreichen neue Erstgenerations-Modelle — insbesondere von iPods und iPhones — regelmäßig Höchstpreise, die nicht selten dem zwei- oder dreifachen des damaligen Originalpreises entsprechen. Zugegeben, diese Wette ist eine teure. Aber wenn die originalverschweißte Apple Watch in 10 Jahren dann 34.000€ wert ist, ist das doch auch kein schlechter Deal.

Disclaimer: Ich trage einen Nomos Tangomat und habe mich vor der Kaufentscheidung hierfür schon länger mit Preisen und Funktionen von teureren Uhren beschäftigt.

Vor ein paar Tagen hat der SPIEGEL einige seiner Artikel mit einer Paywall versehen, wie auch andere Zeitungen und Zeitschriften das schon länger machen. Beim SPIEGEL nennt sich das Ganze SPIEGEL Plus und setzt dabei auf das LaterPay-System aus Deutschland ¹
LaterPay offeriert nach eigenen Angaben den folgenden Service:

Wir bieten die Infrastruktur um das Kaufen und Anbieten digitaler Inhalte jeder Art zu vereinfachen. Dabei bilden die Websites der Anbieter den Marktplatz, LaterPay bedient lediglich die Kasse. Auch Erstnutzer können mit LaterPay mit nur zwei Klicks einkaufen.

Nur blöd, dass man die komplette Paywall mit nur einem Klick umgehen kann. Hey, das ist ja sogar noch einfacher, als das System korrekt zu nutzen!
Wie das funktioniert,

kann man sich hier in einem kurzen Video ansehen:

Und ja, es ist für den Enduser wirklich so simpel. Man zieht sich nur einen Link in seinen Browser, den man immer dann klickt, wenn man gegen eine LaterPay-Bezahlschranke läuft. Selbst mal ausprobieren? Gerne. Also:
Ziehe LaterPay Unlocker in die Favoritenleiste deines Browsers und klicke bei Bedarf darauf. Fertig. Das funktioniert schneller als man B-E-Z-A-H-L-S-C-H-R-A-N-K-E buchstabieren kann. Viel Spass beim Lesen.

Nachtrag: Okay, ich will fair sein und zunächst mal abwarten, was die Betreiber sagen; Code deshalb vorerst mal entfernt.

Hintergrund

LaterPay ist sich bewusst, dass das genutzte System leicht zu umgehen ist, doch man muss hier klar zwischen zwei Wegen trennen:

1. Die Nutzung im vorgesehenen Sinne und deren Lücken
2. Die Implementation der Paywall nebst Auslieferung der Inhalte

Zum ersten Punkt: LaterPay lässt sich mit einem virtueller Bierdeckel vergleichen. Man darf erst einmal aufs Haus sammeln, bevor man zahlen muss; bei einer Summe von fünf Euro muss man diese zahlen und darf nicht weiter anschreiben lassen.

Die virtuellen Striche auf dem Bierdeckel kann man gezielt unter den Tisch fallen lassen, indem man die Cookies des Browsers löscht oder ihn im Privat-Modus nutzt. LaterPay setzt hier zusätzlich scheinbar auf die Identifikation des Users per IP-Adresse, was sich in der Regel durch einen Neustart oder die Neu-Einwahl des Heim-Routers verwürfeln lässt (Stichwort FairTrack-System). Mit ein bisschen Kreativität kann man dem virtuellen Wirt also vorgaukeln, nie einen Bierdeckel gehabt zu haben. So weit, so bekannt.
Mehr kann LaterPay an dieser Stelle auch gar nicht tun, denn das System ist bewusst anonym gehalten und man soll es, bis der Bierdeckel voll ist, auch anonym nutzen können. Die Programmierer sind sich dieser offensichtlichen Lücke wohl bewusst und geben hier der einfachen Nutzung gegenüber der vollständigen Sicherheit den Vorrang.

Viel schwerwiegender wiegt jedoch Punkt 2, die derzeitige Implementation der Paywall: Diese liefert stets den kompletten Artikel inklusive aller eingebundenen Inhalte wie Bilder oder Videos an den Besucher aus, verschleiert diese aber auf zweierlei Art und Weise. Zum einen liegt ein Blur-Filter über dem Content, der den Inhalt verschwommen erscheinen lässt. Diese Hürde lässt sich im Browser einfach deaktivieren, indem das entsprechende Schleier-Element unsichtbar gemacht wird, links vorher, rechts nachher:

Ähnlich geht man dann mit dem „Jetzt lesen, später zahlen“-Banner um: Weg damit. Die Artikelbilder sind nun schon vollständig zu sehen, sind aber noch von grösstenteils unlesbarem Text umrandet:

An sich sieht der Text ja wie ein solcher aus: Leerzeichen, Satzzeichen, Absätze, alles da. Die LaterPay-Macher haben sich dazu entschlossen, den Text auch nicht zu verschlüsseln, sondern zu verwürfeln. Wer sich auch nur ein bisschen für solche Themen interessiert, wird schnell feststellen, dass es sich hierbei um eine Caesar-Chiffrierung mit +1 mod 256 handelt. Die Buchstaben werden also immer bloß um eine Stelle verrückt, aus einem A wird im chiffrierten Text ein B, aus einem B ein C und so weiter. So wird aus

… Ejf 72 Njmmjpofo Fjousåhf- wpo efofo B[ Ejsfdu bvg efs Xfctfjuf tqsjdiu- tfu{fo tjdi mbvu Tqsfdifs bvt ýcfs 41 Njmmjpofo Qptubesfttfo {vtbnnfo- ejf jo fjofs Ebufocbol wpsmjfhfo…

dann durch Zurückchiffrieren der Buchstaben auf einmal ein

… Die 72 Millionen Eintråge- von denen A[ Direct auf der Webseite spricht- set{en sich laut Sprecher aus ýber 41 Millionen Postadressen {usammen- die in einer Datenbank vorliegen …

Das sieht doch schon ganz gut aus. Chiffriert man dann noch die Sonder- und Satzzeichen um, hat man den komplett dechiffrierten Text vor sich. Dankenswerterweise liefert LaterPay das nötige Werkzeug zum Dechiffrieren des Textes in Form der JavaScript-Funktion deobfuscateText() gleich mit, wenn man sich einmal durch die Paywall geklickt hat.

Modifiziert man diese, dass der Seitenschleier zusätzlich weggenommen wird und sie autark funktioniert, kann man sämtliche Seiten entschlüsseln, und das zwar vollkommen im eigenen Browser und ohne Kommunikation mit dem Inhalteanbieter oder LaterPay.

Im Klartext: LaterPay und der Inhalteanbieter können es bei der derzeitigen lächerlich einfach zu umgehenden Implementation der Paywall weder verhindern noch sehen, dass der Besucher selbige mit nur einem Klick in seinem Browser einreißt und die kompletten Premium-Inhalte rezipieren kann. Dies ist nur deshalb der Fall und so bequem für den Free Rider, weil die kompletten Seiteninhalte ausgeliefert werden und nur denkbar simpel chiffriert werden. Für den Server der Gegenstelle ist die nachträglich im Client stattfindende Dechiffrierung nicht zu erkennen.

Was dahinter steckt, will mir nicht einleuchten, denn um den Artikel legal lesen zu können, muss der Besucher ohnehin einmal durch das LaterPay-Tor geschleust werden, wo ihm dann vom LaterPay-Server ein Strich auf seinen virtuellen Bierdeckel addiert wird. Es gibt also technisch überhaupt keine Notwendigkeit, vorher schon den kompletten Artikelinhalt an den Besucher auszuliefern. Er kann ja im unbezahlten Zustand — mit Schleier und Buchstabenverdrehung — allenfalls die Bilder und die Artikellänge erahnen, mehr aber auch nicht. Viel sinnvoller wäre es, den kompletten Artikel erst nach erfolgreichem Strich auf dem Bierdeckel freizugeben: Dann ließe sich das System auch vermutlich nicht so einfach mit einem Klick umgehen. Die Anti-AdBlocker-Wall von BILD lässt sich beispielsweise auch recht leicht umgehen, deren Paywall BildPlus aber nicht ².

Der legale Weg zum Lesen des Artikels ist also länger und „komplizierter“ als das selbstständige Dechiffrieren, weil einmal der Bierdeckel-Umweg genommen wird. Na, dann mal Prost!

Nachtrag: Das WordPress-Plugin von LaterPay bietet seltsamerweise genau das an, was die Implementierung bei den großen Inhalteanbietern vermissen lässt: Es sorgt dafür, dass der komplette Inhalt einer Seite erst dann geladen wird, wenn der User gezahlt hat. Somit funktioniert die hier vorgestellte Methode dort nicht.

Apple-Benutzer sind es gewöhnt, Adapter in der Tasche mit sich herum zu tragen, seit jeher ist das so. Und dennoch ist mit dem iPhone 7 eine Zäsur eingetreten. Ein vormals universal benutzbares Accessoire ist nun nur noch mit iOS-Geräten benutzbar.

Ich erinnere mich noch gut an mein erstes Apple-Notebook, ein 12″ iBook G4. Das muss 2004 gewesen sein. Das Notebook hatte alles, was man so brauchte, inklusive Bluetooth und WiFi b/g, bei Apple AirPort genannt. Wollte man allerdings einen externen Monitor anschliessen, ging das nur per Mini-VGA-auf-VGA-Adapter. Und — damals gab es das iBook und das teurere, Alu-PowerBook — wollte man den Bildschirm nicht bloß spiegeln, sondern erweitern, musste man etwas an der Software rumschrauben. Adapter plus künstliche Einschränkung also.

In all den Jahren mit verschiednen Apple-Rechnern gehörten Adapter immer zum Bild. Sei es der erwähnte VGA-Adapter oder das (kostenlos beim iBook enthaltene) USB-Modem¹ oder später dann Mini-DVI-auf-DVI, USB-auf-Ethernet, Mini-Displayport-auf-DVI, Mini-Displayport-auf-HDMI, Thunderbold-auf-Ethernet, Thunderbold-auf-FireWire oder komplette Thunderbold-auf-Foo-Docks. Bloss Gardena auf 220V habe ich nie genutzt.

Der neueste Schrei ist nun USB-C, und glaubt man den Anhängern, dann tritt man hiermit nun endlich in das gelobte Adapterland ein. Denn USB-C kann, im Gegensatz zu allen vorher genannten, den Rechner auch mit Strom versorgen und gleichzeitig bidirektional Daten tauschen. Alles über eine einzelne Strippe also. Das ist wirklich toll, wenn es funktioniert. Wenn².

Die eben genannten sind nur die gängigsten Schnittstellen an portablen und stationären Macs. Schauen wir auf die mobile Apple-Hardware, dann fängt es bei FireWire400 beim ersten iPod an, setzt sich über den 30-Pin-Adapter der neueren Modelle bis zum heutigen Lightning ³ fort. Und hier gab es auch in jedem Evolutionsschritt mehrere Adapter zu jeweils anderen Standards. In der neuesten Inkarnation des iPhones gibt es nun auch den von vielen geliebten Kopfhöreranschluss nicht mehr. ⁴

Diese Adapteritis hatte früher den Zweck, krasse Änderungen bei Standards weich abzufedern und den Wechsel für Benutzer mit bestehender Alt-Hardware einfacher zu machen. Hatte der erste iMac kein Floppy-Laufwerk mehr, so konnte man es sich doch via USB hinzukaufen, falls man es noch gebraucht hat, gleiches galt für CDs und DVDs, etc pp.

In der Regel ist der von Apple vorher herbeigebrachte Status dann auch in ein paar Jahren im Mainstream angekommen. Niemand nutzt heute mehr Floppy-Disks und auch USB-Sticks sind selten geworden. Exoten wie SCSI und ZIP-Laufwerke sind auch aufgefressen worden. Selbst wenn die Schnittstellen noch aktuell wären, die dahinter liegenden Techniken sind auch obsolet geworden. Doppel-Patt also. In der gleichen Zeit, in der man früher eine ZIP-Diskette in ein Laufwerk geschoben hat, hat man heute diese Daten um den Globus geschickt.

Diese Fortschrittswendung sehe ich bei Apples aktueller Politik aber nicht, da sich viele Standards vermischen und sich teilweise gegenseitig aufheben können. Ein Beispiel: Früher war der USB-Anschluss dem alten Parallel- und Serial-Port deutlich überlegen. Oft mussten keine Treiber installiert werden, die Hardware konnte während des Betriebs gewechselt werden, die Übertragung ging viel schneller, USB war kaskadierbar mit Hubs und vieles mehr. USB war also in allen Bereichen überlegen. Das dumme war allerdings, dass man ja noch diesen sackteuren SCSI-Scanner da stehen hatte. Was tat man? Klar: Einen Adapter kaufen. Und der nächste Scanner war dann womöglich USB und die Sache war gegessen. Ab da an hatte USB also gewonnen und SCSI konnte persönlich beerdigt werden.

Möchte man heute USB-Hardware an aktuelle Apple-Hardware anschliessen, dann klappt das bei Macs, bei iOS-Geräten steht man aber schon recht dumm da. Mit ein bisschen Glück klappt es dann wieder mit einem Adapter, aber auch nicht immer. Das gleiche Dilemma gibt es in anderer Richtung. Was tut man, wenn man von Apple-Hardware Videos auf einen HDMI-Fernseher bringen will? Im besten Fall hat man einen HDMI-Anschluss am Rechner oder ein AirPlay-Gerät an jenen Fernseher angeschlossen. Ansonsten? Hmm. Fürs iPhone braucht man einen Lightning-auf-HDMI-Adapter, okay. Für das neue MacBook? Ach, anderer Adapter. USB-C-auf-HDMI. Noch ziemlich unausgereift? Einfach mal probieren. Für den älteren Laptop? Ah, einen Mini-DP-auf-HDMI-Adapter, klar. Moment… Ka-Ching… Mal eben gekauft. Klar. Braucht man ja eh.

Der grössere Grundgedanke hier ist »All Ports must die«, was auch nachvollziehbar ist und der Schnittstellen-Evolution dient. Irgendwer muss halt man alte Zöpfe abschneiden und Apple ist eben gut und schmerzhaft darin. Sonst bewegt sich ja nie etwas. Niemand will sein Smartphone per LAN-Kabel anschliessen. Das wird allerdings dann zum Problem, wenn die eigene Landschaft so zerklüftet wird, dass sich konkurrierende Standards überlagern. USB-C kann die gleichen Aufgaben wie Thunderbolt übernehmen. Lightning wiederum ein Subset hiervon. Standards subsidieren Standards. Aber Lightning ist eine pure iOS-Schnittstelle und in macOS bisher nicht verfügbar. Und das reißt die Welten wieder unnötig auseinander. Wenn man die Kopfhörer, die mit dem neuen iPhone geliefert werden, nicht mehr an seinem Mac benutzten kann, dann ist das idiotisch. Punkt. Das rührt nicht daher, dass ich der Kopfhörerbuchse nachtrauere, sondern weil es konkurrierende Standards ⁵ zum gleichen Anwendungszweck auf verschiedener Hardware gibt. Lightning wird hierbei eine besonders tragische Rolle zuteil: Es war seinerzeit der Nachfolder des 30-Pin-Adapters, obwohl sich die OMTP/GSMA Standards-Gruppe bereits 2007 (also etwa zu erscheinen des ersten iPhones, damals noch mit 30-Pin) für Micro-USB als zukünftigen Standard ausgesprochen hatte. USB-C war damals noch nicht in Sicht und so mag es sein, dass Apple sich damals (aus welchen Gründen auch immer; Verdrehsicherheit?) gegen Micro-USB und für einen eigenen Standard entschieden hat. Ein erheblicher Grund hier ist sicherlich auch, das Apple Lizenzgebühren für »MFi«-Produkte ⁶ kassieren kann. Und wenn man als iPhone-Besitzer Verstand hat und sich Ärger ersparen will, dann kauft man nur MFi-Produkte.

Niemand ⁷ hat heute mehr einen SCSI-auf-USB-Adapter, weil es auch die Hardware schlicht nicht mehr gibt. Wenn man allerdings von verschiednen Geräten der aktuellen Hardwaregeneration verschiedene Adapter braucht, um zum Ziel zu kommen, dann ist etwas grundlegend schief gelaufen.

Natürlich kann man sich behelfen, indem man viel so schnurlos wie möglich macht, Bluetooth und WiFi sind ja hier sicherlich die beiden verlässlichsten Kandidaten. WiFi ist das neue USB. Bluetooth ist die neue Klinke. WiFi mit HTTP-Protokollstack ist kompatibler und universeller, als es USB je war. Und das funktioniert erstaunlich gut. In unserer neuen Wohnung habe ich kein LAN-Kabel mehr zur Couch gelegt, schlicht weil das WLAN schnell genug ist. Und den neuen Drucker kann ich überall dort hin stellen, wo Strom ist. Daten kommen über die Luft. Easy. Und wenn mehr Daten fliessen müssen, dann ist das meist im Zuge eines grossen Backups, was der Rechner dann über Nacht von selbst erledigt, wenn er am Strom hängt. Da ist es mir dann auch egal, ob das 2 oder 6 Stunden dauert, ich schlafe eh. Kluges Management kann also zu einem Grossteil einige Nachteile drahtloser Schnittstellen revidieren und das ist toll.

Jedoch gibt es auch bei drahtlosen Schnittstellen einigen Nachholbedarf. Es gibt beispielsweise kein universell unterstütztes Format, um Bewegbild via WiFi auf einen TV zu bekommen. Klar, es gibt DLNA und Miracast, dann noch Roku und FireTV und Chromecast und AppleTV, aber kompatibel ist das alles nicht. Und so ist man auch bei funkender Übertragung wieder in der Falle der konkurrierenden Standards. Zuhause mag das kein Problem sein, weil man sich da auf die Sitten der eigenen Geräte einrichten kann. Aber wehe, ein Freund mit Android-Handy kommt vorbei oder man will die neueste House-of-Cards-Folge auf dem Hotel-TV sehen. Dann wird es schon wieder eng und man nimmt im Zweifelsfall ein HDMI-Kabel oder einen FireTV-Stick mit.

So ganz werden wir sie wohl doch nicht los werden, die Adapter. Aber ich halte es für eine gute Idee, Kabel so weit wie möglich zu reduzieren⁸. Und dennoch habe ich in meiner Laptoptasche ein Micro-USB-Kabel, ein Lightning-Kabel, einen USB-C-Adapter und einen Mini-DP-auf-alles-Adapter. Was denkt ihr darüber?

Dieser Artikel wurde entfernt.

Das Thema Fakenews ist zurzeit stark in den Medien vertreten. Ich habe dabei im persönlichen als auch Online-Umfeld verschiedene Meinungen zum Thema gehört. Die einen sagen, dass es schwierig sei, eine Grenze zwischen tendenziösen Nachrichten, Clickbait-Arschlöchern, Satirewebsites, Hoax und Fakenews zu ziehen. Die anderen sagen, dass Fakenews sehr wohl ein ernst zu nehmendes Problem darstellen und unterstützen die Eindämmung dergleichen. Eine Untersuchung der Uni Standford hat ergeben, das 82% der jungen Jugendlichen echte Nachrichten nicht von gesponsertem Content unterscheiden konnten. Dies sind alarmierende Zahlen und es lohnt sich, hier tiefer ins Detail zu gehen.

Ich möchte meine ganz persönliche Sicht der Dinge hier äußern, vielleicht hilft sie ja dem einen oder anderen, das Thema besser zu bewerten.

Einer meiner Facebook-Freunde ist, was seine Nachrichtenrezeption angeht, alternativ (kann man das wertneutral so nennen?)

Er hat unter anderem schon öfter Beiträge der Seite »Der Wächter« geteilt. Dort teilt man mit einer großen Kelle dampfend gegen all jene Systemmedien aus, verbreitet gerne auch klassische Verschwörungstheorien (»Finanz-Judentum«, Zentralbanken im Besitz der Familie Rothschild etc) und verbreitet ansonsten auch ziemlich jeden Quatsch (beispielsweise »Snowden sagt, Bin Laden lebe«, was auf eine Satirewebsite zurückging). Ein Blick auf die Startseite zeigt schon in etwa, womit man es zu tun bekommt.

Ich habe Facebook-Shares dieser Quelle mittlerweile blockiert, weil dort wirklich selbst der hanebüchenste Schwachsinn geteilt wird. Das erkennt man in der Regel relativ leicht, wenn man sich nach dem vollständigen Lesen des Artikels noch 10 Minuten Zeit nimmt, die dort aufgestellten Thesen zu kontrollieren. (Weiter unten gehe ich darauf ein, wie man Fakenews als solche erkennen kann).

Seit nun das Thema Fakenews größere Beachtung bekommt, werden diese Seiten selbst auch nicht müde, die »Mainstream-Medien großer Konzerne« der Lüge zu bezichtigen. Dies geschieht nicht nur beim Wächter, sondern auch auf ideologisch ähnlich gehaltenen Websites. Unter anderem diese Tatsache hat mich dazu veranlasst, mich genauer mit dem Phänomen zu befassen. Natürlich kann man das ganze Thema auch als Schwachsinn abtun, doch so einfach ist es nicht. Ich muss etwas ausholen:

Unwahre Mitteilungen gibt es wohl schon seit Menschengedenken. Dabei kann man grob zwischen sogenannten Hoax, überspitzten und tendenziösen Quellen, Verschwörungstheorien und Satire unterscheiden. Die inhaltliche Qualität von Hoax und Fakenews liegt oft nicht weiter auseinander. Während Hoax ein altes Phänomen sind, traten Fakenews erst in den vergangenen Jahren auf die Bildfläche. Hoax haben, im Gegensatz zu Fakenews, aber teilweise einen intrinsisch guten Kern. Man will Mitmenschen vor Bösem schützen, (Die Einbrecher sind unterwegs! Schnell bei Facebook teilen! Dummerweise geschah die Sache aber nicht im Nachbardorf, sondern in einem anderen Dorf gleichen Namens Hunderte Kilometer entfernt.) oder vermeintliche gute Infos weiter geben (Der Kältebus für Obdachlose mit leider falschen Telefonnummern ist hier ein Beispiel) oder aber schlicht blenden, hetzen und desinformieren (Q33NY). Bei Fakenews ist der Übergang fließend, denn diese haben meist eine klar tendenziöse Haltung (die Wahrheit!), nebenbei aber auch einen klaren Nutznießer.

Bleiben wir beim Wächter und schauen uns dort einmal um. Im Impressum der Seite ist Anonymous Ltd., Borsigstrasse 9, 10115 Berlin genannt. Geht man auf die Suche nach dieser Adresse, stößt man schnell auf Ungereimtheiten. Die (von mir nicht sonderlich geschätzte) WELT hat sich dort mal umgeschaut und dort den Briefkasten-Vermittler ClevverMail ausgemacht. Das scheint ein windiges Business zu sein, denn im Oktober 2009 gab es die Briefkastenfirmen dort noch nicht. Man zahlt also einer Firma Geld dafür, ein physische Adresse irgendwo zu haben, wo man gar nicht ist. Diese Firma scannt dann Briefe ein und leitet sie digital weiter. Praktisch. Nun ist die Abwesenheit eines Impressums noch nicht unbedingt ein Grund zur Sorge (man schaue sich nur diese Website an…), aber es kann einen schon stutzig machen. Spätestens, wenn man sich nach Lektüre einiger Storys dann auf der Jobs-Seite noch liest, dass man freie Mitarbeiter suche und man 3 Cent pro geschriebenem / übersetztem Wort verdienen kann, könnte man hellhörig werden. Es gibt keine Namen, keine Adresse, keine Firmierung, nur eine E-Mail-Adresse. Man kann natürlich auch argumentieren, dass reptiloide Mossad-Agenten den Redakteuren auf den Fersen sind, aber die tatsächlichen Gründe dürften weitaus schnöder sein. Beispiel gefällig? Schauen wir uns mal diesen Text an, den ich via Facebook gesehen habe. Hitler geht doch immer, oder? Also:

FBI-Dokument veröffentlicht: So sind Hitler und Eva Braun nach Argentinien geflohen

Das sind Tatsachen! NEIN! DOCH! OOOH! Schockierend! Warum wusste das denn vorher niemand! Skandal! Der Wächter enthüllt:

70 Jahre lang hat man der Welt erzählt, dass Adolf Hitler am 30. April 1945 in seinem unterirdischen Bunker Selbstmord begangen hat. Sein Körper wurde von den Sowjets entdeckt und identifiziert, bevor er zurück nach Russland mitgenommen wurde. Ist es möglich, dass die Sowjets die ganze Zeit über gelogen haben und, dass die Geschichte neu geschrieben wurde? Nach der Veröffentlichung dieser FBI-Dokumente scheint es nun auf jeden Fall so zu sein, dass der berüchtigtste Führer der Geschichte aus Deutschland entkommen ist und einen friedlichen Lebensabend in den Ausläufern der Anden in Südamerika verbracht hat.

Bevor jetzt alle Lügenpresse schreien, sollte man sich alles etwas genauer ansehen: Liest man den Wächter-Text zu Ende, kann man felsenfest davon überzeugt sein, dass Hitler lebt und in Südamerika lebt. Diese Theorie ist ja quasi schon so alt wie der 2. Weltkrieg. Aber wenn das FBI das alles noch unterstützt: Was kann da schon schief gehen? Einiges. Erstens ist der Text beim Wächter überhaupt nicht selbst geschrieben, sondern bloß eine 1:1-Übersetzung von AnonHQ.com (wie circa 70% aller beim Wächter veröffentlichten Texte), immerhin wird am Ende die Quelle samt Link genannt. Der gleiche Text findet sich also dort auf Englisch wieder, lustigerweise ist der letzte Satz […] Did Hitler escape to Argentina? The answer is yes. aber nicht beim Wächter angekommen.
Schauen wir uns mal das verlinkte FBI-Dokument genauer an. Der Text lässt sich nicht besonders gut lesen, deshalb sollte man aber nicht den Fehler machen, sich auf die Zusammenfassung des Wächters bzw. AnonHQ zu verlassen. Der erste Brief in der FBI-Sammlung geht auf einen Mann ein, der einen Zeitungs-Reporter des LA Examiner getroffen hat und über zwei Ecken gehört haben will, dass jemand sich sehr sicher sei, Hitler sei mit zwei U-Booten nach Argentinien geflohen. Dummerweise konnte die Quelle aber nie aufgetan werden, so sehr sich der Reporter auch bemüht hat. Diese Misserfolge und leeren Versprechungen ziehen sich durch alle anderen Briefe durch. Die Existenz dieser Dokumente beweist keineswegs, dass Hitler es sich in Südamerika gemütlich gemacht habe, sondern nur, dass das FBI jeder noch so schwachsinnigen Spur nachgegangen ist oder zumindest Informationen zu solchen gesammelt hat. Beim Wächter liest sich das natürlich ganz anders, nichts weniger als die Neuschreibung der Geschichte wird ausgerufen.

Und auch das vor kurzem aufgetauchte Foto beweist — gar nichts. Das ist nämlich so körnig und detaillos, dass man keine Person erkennen kann, das Gesicht lässt jegliche Zeichnung vermissen. Geht man dem Foto etwas genauer nach (die Google-Rückwärts-Bildersuche hilft), erfährt man, dass es sich bei dem Foto um eine Seite aus dem Buch Hitler in Brazil – His Life and His Death handelt, bei dem Simoni Renee Guerreiro Dias, eine brasilianische Autorin behauptet, Hitler lebe seit langem in Ihrem Land und sie wolle das auch mittels eines DNA-Tests beweisen. Ähnliche Unsinns-Geschichten findet man beispielsweise auch über den Priester Krespi, der angeblich auch Hitler gewesen sein soll. Und genauso verhält es sich auch mit den übrigen wiedergegebenen, angeblich unwiderlegbaren Fakten: Überspitzungen, Verkürzungen, Verdrehungen, nur um eine Story zu bekommen.

Das ist im Falle der Hitler-Story natürlich aus heutiger Sicht nicht mehr besonders relevant — Selbst wenn dieser überlebt hätte, er wäre heutzutage längst tot. Die Räuberpistolen schmerzen in diesem Falle eher niemanden.

Das kann aber auch ganz anders aussehen, wie man derzeit auf Facebook immer wieder sieht:
Solche als Bild mit Text aufbereiteten und einfach teilbaren Zitate werden hundertfach verbreitet und kommentiert, man kann die Wut der besorgten Bürger förmlich riechen. Nichts weniger als der Untergang des christlichen Abendlandes steht bevor! Weihnachtsbäume! Diese verdammten linksgrünversifften Schweine! Wie können die nur?

Die Sache hat bloß einen kleinen, aber entscheidenden Haken: Norbert Czerwinski hat das nie gesagt. Das komplette Zitat ist erfunden und ihm in von Halle-Leaks den Mund (beziehungsweise neben sein Konterfei) geschrieben worden, der Text ist mit den Schlagwörtern Asylterror und Politmaden versehen. Noch Fragen? Tatsächlich stand zur Diskussion, ob es nicht sinnvoller sei, einen Baum zu pflanzen und diesen dauerhaft stehen und wachsen zu sehen statt jedes Jahr einen neuen großen Baum zu schneiden. Das hängt wieder oberflächlich miteinander zusammen und das kann man finden, wie man will: Mit Flüchtlingen hat dies aber überhaupt nichts zu tun.
Man sollte allerdings wissen, dass Halle-Leaks von Sven Liebich, einem Rechtsradikalen und ehemaligen »Blood&Honour«-Mitglied betrieben wird.

Die Manipulation ist hier deutlich perfider, denn es werden gezielt Zitate genutzt und verfälscht, um Ressentiments gegen Flüchtlinge zu schüren. Übrigens ist auch schon im Halle-Leaks-Text gar nichts mehr vom Zitat im Bild zu lesen, aber das scheint den Facebook-Hetzern egal zu sein.

Ob Hitler oder Weihnachtsbaum: Die Maschen sind ähnlich und allzu oft soll ein Empörungungsreflex der Rezipienten angesprochen werden. Fälle wie der Weihnachtsbaum sind beileibe kein Einzelfall. In Facebooks geschlossenen Gruppen wie etwa »Die Runde« sind solche Fake-Zitate an der Tagesordnung. Dabei scheint es völlig egal zu sein, wie krude die Aussagen sind. Nutznießer sind hier in der Regel diejenigen, die Angst schüren und verbreiten wollen.

Es wird gezielt Stimmung gemacht und Meinungen werden auf Basis von Falschinformationen manipuliert. Dies scheint erschreckend gut zu funktionieren, wenn man den erschütternden Kommentaren glauben kann.

Es gibt aber noch andere Profiteure: Die Fakenews-Websites und die Betreiber dahinter. Die verdienen mit jedem Seitenaufruf, mit jeder Empörung, mit jeder Zuspitzung und Lüge mit, weil nahezu alle diese alternativen Websites sich über Werbung, Affiliate-Links oder Shops monetarisieren. Dies alleine ist natürlich nicht verwerflich. Millionen anderer Seiten tun dies auch. Es ist aber sehr wohl verwerflich, wenn man alles und jeden ohne Rücksicht vor den eigenen Dreckskarren spannt, nur um damit Klicks und Geld zu generieren.

Wie immer sind die Übergänge bei den Fakenews fließend, in alle Richtungen: Mal mehr, mal weniger Werbung. Mal mehr und mal weniger offensive Meinungen. Alternativ gibt es auch Fakenws, die aussehen wie die Startseiten echter großer Portale. Dort werden aber seltsamerweise dann immer nur obskure Sachen vermeldet: Wahnwitziges Vermehren von Geld oder Vermindern von Gewicht. Auf den ersten Blick sieht alles gut aus, bis dann das Feld zur Eingabe der Kreditkartennummer kommt. Doch nicht immer sind die News so harmlos, denn oft geht es dabei auch immer wieder um die nur allzu bekannte Themen: Schrödingers Flüchtlinge nehmen Deutschen das Abendland, die Arbeit und gleichzeitig Sozialleistungen weg, Israel ist böse, Russland gut, Trump hat’s allen gezeigt, Meinung statt Fakten. Das liest sich leider sehr oft wie ein Best-Of-Kochbuch der »alternativen Medien«: Statt kräftig mit Salz und Pfeffer würzen lieber noch eine Priese Israel-Kritik darüber streuen! Stimmt alles! Stand alles in den Protokollen! Bis zum handfesten Antisemitismus ist es da übrigens nicht mehr besonders weit. Ach Quatsch? Dann einfach mal Facebook-Kommentare durchlesen.

Auch der Wächter schaltet fleißig Werbung und bewirbt Produkte mit Affiliate-Links, von Hass alleine kann man ja auch nicht leben. Zugeben würden die ehrenvollen Ritter der wahrsten Nachrichten das natürlich wohl nicht.

Gegenüber Vice News Tonight (ab 14:43, leider gibt es weder ein Transkript noch die Sendung sonst wo online. Man kann sich das nur anschauen, wenn man ein HBO-Abo hat oder jemanden kennt.) hat Paul Horner, Autor von Fakenews und Inhaber von Domains wie foxnews.com.de, usatoday.com.co und nbc.com.co offen zugegeben, dass seine Geschichten schlichtweg Schwachsinn sind mit dem Ziel, Klicks (und somit Werbegelder) generieren. Er finde nichts schlimmes daran, er könne prima davon leben und sei außerdem auch noch davon überzeugt, dass Trump ganz nebenbei wegen ihm im Weißen Haus sitze.

Was bleibt nun von Fakenws? Wenig Substanz, wenn man die Maschen einmal genauer unter die Lupe nimmt. Leider geschieht das viel zu wenig. Sicherlich kann man auch etablierte Medien kritisieren und auch dort gibt es zuhauf widerliche Gestalten, die des Geldes willen mindestens überzogene, wenn nicht gelogene Geschichten an den Mann und die Frau bringen.
Auch etablierte und große Medien und TV-Anstalten machen Fehler und liegen nicht immer richtig. Sie zu kritisieren ist wichtig und richtig.
Aber all dies ist meilenweit entfernt von der Hetze, den Lügen und den vorsätzlich falsch fabrizierten »News«, die Portale wie Der Wächter oder Halle Leaks verbreiten. Es wäre schon viel geholfen, wenn Google als Betreiber eines der größten Werbenetzwerke Fakenews von der Monetarisierung ausschließen würde, entsprechende Schritte wurden auch schon getroffen.

Paul Horner, der Fakenews-Autor bringt es auf den Punkt:

Honestly, people are definitely dumber. They just keep passing stuff around. Nobody fact-checks anything anymore — I mean, that’s how Trump got elected. He just said whatever he wanted, and people believed everything

Meinungen und Gefühle werden stärker als Fakten. Fakenews können noch so oft widerlegt werden, irgend etwas bleibt immer hängen. Das kann nicht gut gehen und schadet auf Dauer allen — nächstes Jahr ist übrigens Bundestagswahl.

Wie kann man Fakenews und Hoax erkennen?

• Wer hat die Meldung zuerst wann, wo über welchen Kanal gebracht?
• Gibt es mehrere unabhängige Quellen, die Berichte über das Geschehen abgeben können oder zirkelt sich der Kreisel der Berichte am Ende auf eine einzige Quelle ein?
• Sind die verschiedenen Artikel bloß 1:1-Kopien, Übersetzungen, Paraphrasen, Zusammenfassungen oder ähnliches eines bestehenden Artikels oder handelt es sich um eigenen Content?
• Nennt die Meldung ihre Quellen mit Namen und / oder Links?
• Ist die im Text verwendete Sprache neutral gehalten oder werden überspitzende Formulierungen verwendet?
• Sind die im Text genannten Fakten (Personen, Uhrzeiten, Orte, Aussagen, Geschehnisse) schlüssig und stimmig? Es gibt bspw oft Orte mit gleichem Namen an unterschiedlichen Landkreisen oder Ländern oder Zeiten und Orte könnten nicht zusammen passen.
• Lässt sich die Quelle / der Autor in irgendeiner Art verifizieren? Gibt es, falls es sich um eine Website handelt, ein Impressum? Wer / was verbirgt sich hinter Namen und Adresse? Führt eine Google-Suche (Text, Bilder, Maps, Streetview) zu dieser sonderbares zutage?
• Gibt es ergänzende Bilder oder Videos?
• Wenn ja, wie lässt sich deren Authentizität bewerten oder belegen? Was bringt ein Upload bei Google Bilder (Datei auf die Eingabemaske ziehen) zu Tage?
• Wie verhält es sich mit dem »Track Record« der Quelle, d.h. ist sie bekannt dafür, früher schon mit Nachrichten und Neuigkeiten positiv oder negativ aufgefallen zu sein?

All dies sind natürlich keine hundertprozentigen Tipps, sie helfen aber ein großes Stück weiter.

Eine Synology Disk Station ist eine tolle Sache. Man kann mit dem flexiblen Heim-Server wirklich vieles tun (wie ich bereits 2012 geschrieben habe), unter anderem dient das NAS auch als Medienserver.

Hierbei werden die Stärken insbesondere durch die tolle DS-Video-Station-App ausgespielt. Die Video-Station bereitet die eigene Mediensammlung toll auf und liefert Cover, Inhaltsangaben und mehr auf verschiedenste Geräte und Browser. Im Hintergrund kümmert sich die App auch um eine Transcodierung des Videomaterials für das entsprechende Endgerät (sofern die DiskStation genug Power hat, klappt das in Echtzeit).

Besonders viel Spass macht die Sache im Verbund mit einem AppleTV, denn so kann man vom Sofa aus die eigene Filmsammlung durchstöbern und direkt im Heimkino anschauen.
Selbst ohne Video Station streamt die DS Videos via UPnP / DLNA ins Netzwerk: Hier ist das Interface nicht so schön, Filme laufen bestenfalls genau so gut.

Ärgerlich ist allerdings, dass die Video-Station nicht alle Surround-Audioformate unterstützt und insbesondere das geläufige DTS zu Stereo heruntermischt, in der Video-Station als auch via DLNA. In früheren Versionen von Synologys Betriebssystem hat die DTS-Ausgabe an das Wiedergabegerät funktioniert, deshalb kann man davon ausgehen, dass es sich um Lizenzstreitigkeiten handelt. Dies ist insbesondere deshalb ärgerlich, weil DTS neben Dolby Digital ein Standard-Format für Raumklang ist und dementsprechend viele Filme damit codiert sind.

Damit man zuhause nun in den vollen Surround-Genuss inklusive DTS kommt, muss etwas von Hand nachhelfen. Glücklicherweise muss man die Dateien nicht von Hand konvertieren, die DS kann das on-the-fly erledigen. Das hier genannte Setup sollte prinzipiell auch mit einem Chromecast oder anderen Streaming-Sticks funktionieren. Wenn ihr möchtet, könnt ihr gerne einen Kommentar hinterlassen, ob es bei euch geklappt hat.

Wir stehen also vor zwei grundsätzlichen Problemen:

1. Die Video-Station kann DTS-Tonspuren nicht korrekt ausgeben
2. Das Apple TV kann DTS-Spuren, auch wenn es sie korrekt empfangen würde, nicht dekodieren oder auch bloß an einen Receiver durchreichen (der es dann dekodieren könnte)

Für beides gibt es eine Lösung.

DS Video Station

Die folgende Anleitung wurde von mir mit einer Synology DS 716+ unter DSM 6.1 und Video Station 2.2.1-1364 getestet.

1. Zunächst muss man sich eine angepasste ffmpeg-Version besorgen, die einen DTS-Decoder enthält. Das passende Paket gibt es fertig zum Download. Man muss jedoch die für die eigene DiskStation passende Variante auswählen. Welches DS-Modell welcher Architektur angehört, kann man nachschlagen.
2. Dieses Paket wird dann über das Package-Center installiert, im oberen Bereich gibt es einen Button zur manuellen Installation von Paketen. Falls die Installation fehlschlägt, muss man in den Einstellungen des Package-Centers die Installation aus allen Quellen erlauben. Sollte die Installation mit einer Invalid File Format-Meldung fehlschlagen, war die gewählte Architektur nicht korrekt.
3. Nach der Installation wird das Paket gestartet, es sollte dann als running in der Übersicht der installierten Pakete zu finden sein. Hiermit ist Problem 1 von oben gelöst, die DS schickt nun korrekten DTS-Klang mit auf die Reise. Sofern das eigene Wiedergabegerät DTS korrekt decodieren oder weiterreichen kann, sollte man hiermit alles haben, was man braucht.

Nun muss man der Video-Station noch beibringen, DTS on-the-fly zu AC3 / Dolby Digital umzuwandeln, damit der Ton auch auf solchen Geräten, die kein DTS verstehen, wiedergegeben werden kann, obiges Problem 2.

4. Hierzu erst einmal in den Einstellungen des Video-Station unter Advanced den AC3-Passthrough für Apple TV aktivieren.
5. Anschließend via Terminal per SSH zur Diskstation verbinden (etwa ssh -l deinuser 10.10.10.10), wobei 10.10.10.10 hier die IP-Adresse und deinuser dein, äh, Username auf der DS ist (ach!) und sich dann via sudo -i zu root machen.
6. Dann die Datei /volume1/@appstore/VideoStation/etc/TransProfile editieren, beispielsweise mit vi:

   vi /volume1/\@appstore/VideoStation/etc/TransProfile

   Nach der Zeile mit dem Eintrag mpegts_remux_lame_ab256_ac2 suchen und deren Wert wie folgt verändern (i drücken, um in den Insert-Modus zu wechseln):

   mpegts_remux_lame_ab256_ac2": "-threads 0 -vcodec copy -vsync 2 -vbsf h264_mp4toannexb -c:a ac3 -b:a 640k -f ssegment

   Anschließend die ESC-Taste drücken, um den Insert-Mode zu beenden, die Datei speichern und vi beenden. Hierzu :wq eingeben und Return drücken.

Nun dekodiert die Video-Station DTS-Audio in Echtzeit zu AC3 (Dolby Digital) für die DS Video App auf dem Apple TV. Das Apple TV gibt den Surround Sound korrekt aus. Die CPU-Belastung meiner DS716+ Liegt hierbei bei max 30-40%.
An meinem Hifi-Receiver wird der Ton-Codec im Display angezeigt: Vor der Änderung wurde der Ton nur als Stereo-PCM durchgegeben, nun wird er korrekt als Dolby Digital gezeigt; die Live-Transcodierung funktioniert. Zum Testen einfach einen Film starten, dessen Infos in der Video Station anzeigen, dass er über DTS-5.1-Ton verfügt.

Viel Spaß im Heimkino bei tollem Surround-Sound! :-)

Online-Werbung und -Tracking sind eine Qual. Das muss ich niemandem erzählen, jeder, der viel im Internet unterwegs ist, weiß das.

Technisch affine Personen haben vielfach einen Adblocker im Browser auf ihren Geräten installiert.

Diese Browser-Plugins gibt es seit über 10 Jahren und die Erkennungsquote ist dank vieler ausgefeilter Regeln auch wirklich nahezu 100%. Mit ein bisschen Mühe kann man sogar auch die Hardcode Anti-Adblock-Seiten wie sueddeutsche.de oder bild.de werbefrei machen, wenn man es denn möchte. Ob man Bild lesen sollte, sei dahin gestellt, für die SZ kann man sicherlich auch einfach den Adblocker deaktivieren.

Adblocker dienen nicht nur dem Filtern von Werbung, sondern dienen auch dem Schutz vor Tracking und Malware. Es sind dutzende Fälle bekannt, bei denen über »verseuchte« Werbung Schadsoftware auf PCs installiert wurde. Ich sehe deshalb Werbeblocker als digitale Notwehr und Selbstverteidigung an. Viele Websites sind im ungefilterten Modus überhaupt nicht mehr zu ertragen oder zu benutzen und neben nerviger Werbung landen auch allerlei Telemetrie- und Trackingdaten auf dem eigenen Rechner. Werbeblocker sind also ein effektiver Weg, die eigene Datenleitung zu schonen, nervige Werbung kalt zu stellen und Tracking zu verhindern.

Das kann man anders sehen und dazu gibt es sicherlich auch gute Argumente. Wenn aber selbst Google, das seinen Umsatz zum aller größten Teil aus Werbung bezieht, einen Adblocker vorstellt, sollte klar sein, dass es hier ein echtes Problem gibt.

Nun gibt es in normalen Haushalten nicht mehr nur traditionelle PCs, sondern auch mobile Geräte und auch Internet-of-Things-Geräte oder »smarte« TVs. Auch Smartphones oder Tablets sind oft außerhalb des Browsers werbeverseucht, gerade viele kostenlose Spiele blenden viel Werbung ein.

Auf diesen Geräten ist es meist schwer / unmöglich, einen Adblocker oder Filter zu installieren. Hier greift eine traditionelle Adblocking-Software nicht mehr.

Seit einiger Zeit gibt es mit Pi-Hole ein sehr cleveres Projekt, mit dem man der lästigen Werbung und dem neugierigen Tracking im gesamten Heimnetzwerk den Garaus machen kann.

Allgemeines

Pi-Hole setzt dabei, im Gegensatz zu klassischen Werbeblockern in Browsern, auf Host-Listen, blockt also komplette (Sub)Domains wie beispielsweise googleadservices.com. Google nutzt diese (und viele andere Domains), um Werbung an Clients auszuspielen.

Die Open-Source-Software setzt hier beim DNS an, der Hostnamen in IP-Adressen umsetzt. Wer nicht weiss, was das ist, kann sich das als eine Art Telefonbuch vorstellen. Menschen können sich Namen und Buchstaben sehr einfach merken, Zahlen und Ziffern eher schwer. Bei Computern ist es genau anders herum.
Der DNS schlägt nun also die zu einem Domainnamen passende IP-Adresse (ähnlich einer Telefonnummer) nach. Und Pi-Hole funkt hier eben dazwischen, wenn erkannt wird, dass gerade die »Telefonnummer« von »Werbebude« nachgeschlagen werden soll, normale Domains werden durchgelassen. Pi-Hole ist quasi ein netzwerkweiter Türsteher: Wann immer eine Website Werbung und Tracking von bekannten bösen Domains nachladen will, wird dies verhindert.

Dieser Ansatz ist sehr clever, weil er sehr transparent funktioniert und im Gegensatz zu einem Proxy sehr leicht via DHCP automatisch auf alle im Netzwerk verbundenen Geräte gepusht werden kann und auch ansonsten völlig konfigurationslose oder völlig dumme Geräte wie bspw ein Amazon-Dash-Button mit einbezogen werden können. DNS muss jedes internetfähige Gerät können, ohne Ausnahme. ¹.

Dies ist auch besonders interessant für Smart-TVs, die in der Vergangenheit dadurch aufgefallen sind, dass sie sehr viel und häufig mit dem Server des Herstellers kommunizieren. Ebenfalls äußerst lästig ist per HbbTV ins Live-Bild eingestreute Werbung, die aus dem Internet nachgeladen wird. Kostenlose Handyspiele finanzieren sich ebenfalls oft über Werbung, die direkt in die Apps eingebettet ist. All dies lässt sich mit einem zentralen, konfigurierbaren DNS bekämpfen, indem man erwünschte Services passieren lässt, während man alles nervige aussperrt.

Werbung auf DNS-Ebene zu blocken, hat leider auch seine Grenzen: Denn werden Werbung und Content von der gleichen Domain ausgespielt, gibt es für Pi-Hole keine Möglichkeit, dies zu unterscheiden. Rein technisch ist es auch nicht möglich, einzelne Teile von Seiten zu blockieren, wie dies Werbeblocker im Browser tun. Dies ist der Fall, weil der eigentlich Content überhaupt nicht über Pi-Hole geleitet wird, sondern Pi-Hole lediglich IP-Adressen auflöst ².

Deshalb empfehle ich auch, Pi-Hole als erste Stufe einer mehrstufigen Abwehrstrategie zu verwenden und zusätzlich noch einen Werbeblocker im Browser ³ zu aktivieren. Pi-Hole kümmert sich darum, dass der gröbste Dreck überhaupt nicht über die Hausschwelle kommt, der Blocker im Browser erledigt den Rest und ist für die Feinheiten zuständig.

Damit Pi-Hole Werbung für das ganze Network blocken kann, muss man die Software logischerweise installieren. Pi-Hole läuft, wie der Namen vermuten lässt, natürlich auf einem Raspberry Pi, darüber hinaus aber auch in ähnlichen Debian-Umgebungen. Es gibt auch Docker-Container, so dass man Pi-Hole flexibel installieren kann, wie es am besten passt.

Installation

Ich habe einen alten Raspberry Pi 1 aus dem Schrank genommen, für den ich momentan keine andere Verwendung hatte. Für Pi-Hole eignet er sich ideal, auch wenn er etwas schwach auf der Brust ist. Der Load liegt normalerweise bei ca 20-30%, bloß beim Einspielen / Updaten von Filterlisten ackert der kleine ganz schön, was aber nur einmal am Tag passiert. Von daher alles im grünen Bereich und die alte Hardware wird einem sinnvollen Zweck zugeführt. :-)

Die Installation von Pi-Hole v3 auf einem Raspberry Pi ist sehr simpel. Der Pi muss dabei über keine grafische Oberfläche verfügen, denn Pi-Hole bringt ein eigenes Web-Interface mit. Es reicht also völlig, sich per SSH mit dem Pi zu verbinden und das Installationsskript auszuführen. Alternativ geht es natürlich auch via Monitor, Tastatur und Shell. Es ist wichtig zu wissen, dass Pi-Hole für die effektive Unterdrückung einen freien Port 80 braucht. Dort (auf eine leere Seite) werden die geblockten Hosts weiter geleitet. Möchte man Pi-Hole also auf einem Gerät installieren, dass schon ein Webinterface auf dem Standard-Port 80 laufen hat, muss man dies umkonfigurierten.

Wie die Installation funktioniert, ist auf der Homepage gut erklärt ⁴, im Prinzip einfach curl -sSL https://install.pi-hole.net | bash eingeben und warten.

Anschließend führt ein grafischer Installer durch den Prozess, einige Parameter werden abgefragt. Bei der Installation ist es wichtig, die gewünschte / korrekte Netzwerkschnittstelle des Pi auszuwählen und dieser auch eine feste IP im Heimnetz zu geben, sonst wird man später im Betrieb Probleme bekommen.
Ich empfehle dringend, die Weboberfläche und das Logging mit zu installieren, denn sonst ist die Konfiguration nur per Shell möglich. Machbar, aber kompliziert.

Nachdem die Installation durchgelaufen ist, wird das Admin-Passwort des Web-Interfaces angezeigt. Dieses Passwort kann man per SSH ändern, indem man pihole -a -p neues-passwort eingibt. Das Passwort kann auch per pihole -a -p deaktiviert werden. Es empfiehlt sich ebenfalls, nun per pihole -g die installierten Filterlisten zu aktualisieren.

Die Oberfläche des Pi-Hole erreicht man über die IP, die man vergeben hat, bspw. http://10.10.10.123/admin bzw. http://pi.hole/admin (falls der DNS schon funktioniert).

Konfiguration fürs komplette Netzwerk

Damit das komplette Netzwerk nun Pi-Hole nutzen kann, mann man in seinem Router nun den DNS auf die Pi-Hole IP-Adresse ändern. Nur so ist sicher gestellt, dass wirklich aller Traffic durch den Blocker geleitet wird. Theoretisch oder zum Testen kann man den DNS auch händisch auch auf einzelnen Geräten ändern, das ist aber nicht empfehlenswert bzw. schlicht unbequem.

Wie man genau den DNS im Router ändert, ist von Fall zu Fall unterschiedlich, in der Regel ist es aber sehr einfach. Ist die Änderung durchgeführt, kann man bei den verbundenen Clients nun noch den DHCP-Lease erneuern, damit der Client die neuen Informationen / den neuen DNS sofort serviert bekommt. Früher oder später passiert dies aber ohnehin automatisch.

Sollte der eigene Router es nicht erlauben, den DNS zu setzen / ändern, kann man auch den im Pi-Hole eingebauten DHCP-Server aktivieren (nachdem man den Standard-DHCP-Server im Router deaktiviert hat!), dann vergibt der Pi-Hole fortan die internen IP-Adressen des Netzwerks und stellt auch sicher, dass die DNS-Anfragen an ihn und nicht mehr an den Router gestellt werden.

Welche Konfiguration man hier wählt, kommt sicher auf den eigenen Geschmack und die Bedürfnisse im Netzwerk an, Pi-Hole ist mit dem eingebauten DHCP jedoch äußerst flexibel.

Ist nun alles eingerichtet und die Clients kennen den neuen DNS, kann man eine Runde auf seinen Lieblings-Websites drehen und in der Weboberfläche des Pi-Hole nachsehen, ob die Requests eingegangen sind, was und wie viel geblockt wurde. Die Oberfläche ist hier sehr aufgeräumt und selbsterklärend. Das gilt überhaupt für das komplette Projekt, das sehr gut gepflegt und durchdacht ist. So aktualisieren sich die Filterlisten beispielsweise automatisch und man muss sich um sehr wenig kümmern.

Wichtig zu erwähnen sind die eingebauten Black- und Whitelists, in die man Domains eintragen kann, die auf jeden Fall immer oder nie geblockt werden sollen. Diese Einträge überstimmen die Listen, in denen tausende von Domains enthalten sind.

In der Konfiguration kann man sich nun auch noch überlegen, statt der standardmässig angebotenen Google-DNS-Server andere, zensur- und logfreie Server einzurichten. Das geht ganz einfach, indem man die IPs dieser Server einträgt.

Wem die eingebauten Blocklisten noch nicht umfangreich genug sind, findet im Internet noch viele weitere Listen. Eine gute Übersicht gibt es bei Wally3k. Das Aktualisieren der Listen kann etwas dauern und man sollte nicht unbedingt nach dem Motto mehr ist mehr vorgehen, denn alle Listen müssen im RAM gehalten werden. Außerdem steigt mit vielen Listen die Gefahr für Duplikate oder falsche Hosts an. Glücklicherweise lässt sich dies aber auch sehr gut steuern, denn in der Pi-Hole-Weboberfläche gibt es die Möglichkeit, herauszufinden, warum eine bestimmte Domain geblockt wurde.

Wem Pi-Hole gefällt, sollte über eine Spende an die Entwickler nachdenken.

Happy Surfing!

Sicherlich wissen einige von euch, dass ich seit längerem ein Synology NAS als zentralen Datenspeicher zuhause habe.

Das NAS leistet dabei gute Dienste als zentraler Datei-, Medien- und Photoserver, kann aber einiges mehr, wie ich auch schon an anderer Stelle beschrieben habe.

Seit kurzem betreibe ich auch eine private Website (diese hier jedoch [noch] nicht) auf dem NAS, was erst einmal ungewöhnlich klingen mag. Doch auf den zweiten Blick stellt sich heraus, dass die Lösung einige Vorteile gegenüber klassischen Webhosting-Angeboten hat.

Mein Projektziel war es, eine WordPress-basierende persönliche Website mit eigener Domain und SSL-Zertifikat auf meinem Synology-NAS zu betreiben und damit so wenig wie möglich am eigenen NAS-Betriebssystem ändern zu müssen. Fehlkonfigurationen oder andere Nachlässigkeiten könnten ansonsten das komplette NAS gefährden — viel zu riskant. Idealerweise sollte das ganze Setup auch portabel sein, falls mal ein Wechsel bei System, Hard- oder Software ansteht. Dieses Ziel wurde erreicht und ich möchte euch nun im Folgenden beschreiben, wie alles konfiguriert ist. Dies am Beispiel von WordPress mit LAMP-Stack. Grundsätzlich lässt sich die Vorgehensweise via DSM und Docker aber auch für jede andere Umgebung (MEAN-Stack etc.) oder andere Software (bspw. OwnCloud) umsetzen, es müssen dann natürlich andere Docker-Images gewählt und ggf. andere Konfigurationen getätigt werden.

Dieser Beitrag ist ziemlich lang, weil ich ausführlich beschrieben habe, was zu tun ist. Um das Beschriebene nachvollziehen zu können, solltet ihr zumindest über grundlegende Linux- und Terminal-Kenntnisse verfügen und außerdem wissen, wie DNS funktioniert. Ebenfalls solltet ihr nicht auf Kriegsfuß mit eurem Heimnetz stehen und wissen, was Portweiterleitungen sind und wie man Sie einrichtet. Ich gehe außerdem davon aus, dass euer Synology-NAS korrekt funktioniert und ihr (idealerweise) auch eine Synology Dyn-DNS-Konfiguration zur Erreichbarkeit des eigenen NAS über das Internet konfiguriert habt.

Ihr solltet euch ebenfalls im Klaren sein, was ihr den ganzen Prozess über tut und das am Ende quasi euer eigener Server im Internet steht und erreichbar ist. Ihr seid fortan für den Server verantwortlich, es gibt niemanden, der automatisch Patches oder Updates installiert. Das ist ein großer Unterschied zu normalen Shared-Hosting-Umgebungen, wenn auch einige Gefahren durch das Docker-Setup minimiert werden. Bitte kopiert aber bloß nicht blind Befehle fügt sie als root in eine Shell ein — das kann gefährlich sein.

0) Docker?

Tollerweise unterstützen einige moderne NAS-Systeme mit x86-CPU die Software Docker — ein gewaltiger Sprung und großer Vorteil für Heim-Hardware. Denn mittels Docker lassen sich Anwendungen und komplette Betriebssysteme quasi virtualisieren, isolieren und bewegen, ohne dabei die Konfiguration, Hard- oder Software des Host-Systems (des NAS) modifizieren zu müssen.
Man kann somit Betriebssysteme mit Anwendungen installieren, konfigurieren, kopieren, starten und stoppen, ohne direkt das Host-Betriebssystem des NAS anfassen zu müssen.

Ein Docker-Container — ein lauffähiges, virtuelles Betriebssystem — erhält somit Ressourcen, die komplett vom Host getrennt sind und hat auch nur eingeschränkten (oder gar keinen) Zugriff auf die Host-Umgebung.
Vergleichbar ist dies mit virtuellen Maschinen, die man im Profi-Umfeld schon seit langem einsetzt, allerdings werden bei Docker die Host-Ressourcen nicht durch Virtualisierung, sondern durch Rechtemanagement geschützt.

Zur Popularität von Docker trägt auch der zentrale Hub bei – ein Verzeichnis von Docker-Images, die man mit wenigen Handgriffen installieren kann.

Mit DSM 6 hat Synology auch noch eine schöne grafische Oberfläche für Docker bereit gestellt — sodass man neben dem klassischen Weg über die Kommandozeile die allermeisten Sachen auch in der webbasierten UI erledigen kann. Ein echter Vorteil für nicht so versierte Nutzer.

Neben der Verkapselung via Docker ist es ein ungemein beruhigendes Gefühl zu wissen, wo genau die eigenen Daten liegen — nämlich im eigenen Wohnzimmer und nicht in irgendeiner fremden Serverfarm, über deren Prozesse und Abläufe man keine Kontrolle hat. Sicher gibt es auch gute Gründe für Hosting in Rechenzentren oder bei AWS — aber denkt dran: Es soll hier um eine persönliche Website gehen, nicht um ein riesengroßes Business-Projekt. Meine DSM ist in englischer Sprache, die Screenshots sind also möglicherweise etwas anders als bei euch.

1) Docker-Image einrichten

Docker kann auf dem NAS mit Hilfe des »Package Centers« mit einem Klick installiert werden. Ist Docker dort nicht zu finden, ist das eigene NAS-Modell leider nicht kompatibel. Docker läuft dann auf dem DSM mit grafischer Oberfläche und ist recht einfach zu bedienen. Sucht man im Docker-Hub nach »Wordpress«, wird man schnell fündig. Zu beachten ist jedoch, dass jedes der Pakete einen unterschiedlichen Leistungsumfang hat. So bietet das offizielle WordPress-Image beispielsweise keinen MySQL-Server, den man von Hand im Container nachinstallierten oder separat betreiben müsste — machbar, aber aufwändig. Passender war für mich das docker-wordpress-cli-Paket von Kai Hofstetter, dass clever vorkonfiguriert ist und die wichtigsten Einstellungen per Laufzeitvariablen unterstützt und zudem noch Support für WordPress-CLI mitbringt.

Docker-Hub

Je nach Geschmack wird man auch in diesem Paket auch einige Kleinigkeiten noch konfigurieren müssen, dazu später mehr.

Das Image lädt man bequem per DSM herunter, anschließend sollte man es im »Images«-Bereich wiederfinden:

Der Container kann nach dem Download nun generiert werden

Per Klick auf den »Launch« Button wird der Assistent zum Starten eines Containers angezeigt. Hier empfiehlt es sich, den späteren Domainnamen als Containernamen einzutragen und die Ressourcen des Containers auf ein vernünftiges Level zu begrenzen. Ich habe bei 8GB RAM im NAS 512 MB RAM und die mittlere CPU-Begrenzung für das Image gewählt. Je nach eigener Hardware und geplanter Auslastung solltet ihr hier eventuell andere Werte eintragen. Anschließend durchlaufen wir den Assistenten in der erweiterten Einstellung, klickt also auf »Advanced Settings«.

Die Einstellungen des Container-Wizards

Hier legen wir eine Reihe von Parametern fest: Der Container soll bitte von selbst neu starten, falls er ungeplant beendet wird.
Im Reiter »Volume« kann ein Austauschordner zwischen NAS und Docker-Container festgelegt werden. Dieser virtuelle Order wird im Container bereit gestellt und dort gespeicherte Daten wandern aber tatsächlich in einen Order des NAS. Ich nutze diese Funktion im Zusammenhang mit einem WordPress-Plugin als Backup-Option und stelle einen lokalen Ordner innerhalb von WordPress zur Verfügung. Das Plugin sichert die Daten dort rein und sie landen dann direkt auf dem NAS, wo sie in mein normales Backup mit einfließen.
Doch zuerst muss WordPress installiert und die Basis-Ordnerstruktur angelegt werden — wir legen den Austauschorder später fest und tragen hier zunächst nichts ein.

Im »Network«-Reiter ist für unser Projekt nichts zu ändern, wohl aber bei den Ports: Da WordPress im Gespann mit MySQL läuft, braucht es zumindest die Ports 80 (Apache / HTTP) und 3306 (MySQL) zur Kommunikation zur Außenwelt. HTTP wird dabei ins Internet weiter geleitet, MySQL sollte tunlichst im eigenen Heimnetz bleiben und nicht ins Internet bereit gestellt werden. Standardmäßig werden diese beiden Ports auf zufällige Ports des Host-Systems gemappt. Es empfiehlt sich hier aber, feste Ports zu wählen, denn dies macht das spätere Debugging um ein Vielfaches einfacher und es erlaubt auch, aus dem eigenen Heimnetzwerk direkt auf die SQL-Datenbank zugreifen zu können. Die Ports werden also auf dem Host bereit gestellt und in den Container geroutet. Ich habe hier die Ports 10000 und 10001 gewählt, grundsätzlich ist es egal, welche Ports man wählt. Man sollte allerdings keine Standardports (80, 21, 22, 25 etc) blockieren und sich ungenutzte, hohe Ports oberhalb von 10000 suchen. Wer ganz sicher gehen will, dass der Port ungestört ist, kann sich einen Port aus der Reihe der Ephemeral Ports aussuchen.

Die Port-Einstellungen des Containers.

Der Bereich »Links« kann wieder unangetastet bleiben. Beim »Environment« kommen nun die von Kai vorgesehenen Variablen zum Zug — allen voran Datenbank- und WordPress-Usernamen und -Passwörter. Mit Klick auf dass (+) fügen wir bei den Variablen eine neue Reihe hinzu und setzen WP_ADMIN_USER mit einem selbst gewählten Wert ein — bitte auf keinen Fall admin nehmen! Das gleiche dann mit WP_ADMIN_PASSWORD, MYSQL_WP_USER und MYSQL_WP_PASSWORD tun und ein vernünftiges Passwort verwenden. Es ist wichtig, diese Parameter vor dem ersten Start des Containers zu setzen, denn nur so beachtet das interne Konfigurations-Script diese. Die Parameter sind später auch noch im Plaintext innerhalb Docker sichtbar, man läuft also nicht Gefahr, Usernamen oder Passwörter zu vergessen. Den Parameter WP_URL lassen wir zunächst weg, denn diesen werden wir in der SQL-Datenbank ändern, da sich der Hostname später noch mehrmals ändern wird.

Die verschiedenen Parameter, die in den Container übergeben werden.

Der Assistent wird dann mit Klick auf »OK, Next« abgeschlossen.

Unser laufender Container.

Im Bereich »Container« sollte der neu erschaffene Container nun zu sehen sein. Er sollte laufen und etwas CPU und RAM geschluckt haben. Schauen wir doch mal mit Klick auf »Details« rein. Wir sehen laufende Prozesse und im Log, das (mit Ausnahme von sendmail, dazu später mehr) alles funktioniert hat und WordPress fertig konfiguriert wurde.

Die Log-Datei des Containers

Nun, da WordPress läuft, können wir noch den Austausch-Ordner zum Host-System hinzufügen. Änderungen an der Container-Konfiguration lassen sich aber nur durchführen, wenn der Container nicht läuft, also müssen wir in erst stoppen.
Nun können wir im Bereich »Volume« den Ordner hinzufügen, beispielsweise als /var/www/html/wp-content/uploads/wp_2_nas. Dieser Order ist innerhalb von WordPress erreichbar und beschreibbar, da /var/www/html/ der Standard-Dokumentenpfad von Apache ist. Um welchen lokalen (Unter)Ordner auf dem NAS es sich hier handelt, ist Geschmacksache.

Wir speichern die Konfiguration und starten den Container wieder. Nun müssen wir noch einige Kleinigkeiten konfigurieren, die das Leben vereinfachen:
Zunächst muss der oben eingerichtete Austauschordner von jedem innerhalb des Docker-Systems beschreibbar gemacht werden. Hierzu öffnen wir die Details des Containers und erstellen unter »Terminal« mit dem »Create«-Button ein neues Terminal. Dieses wird innerhalb weniger Sekunden als bash auf der linken Seite sichtbar:

Das Terminal – wir befinden uns nun im Container

Nun befinden wir uns, eingeloggt als root, innerhalb des Containers. Hier bearbeiten wir nun die Berechtigungen des Austauschorders:

chmod 777 -v /var/www/html/wp-content/uploads/wp_2_nas

Per -v-Parameter seht ihr genau, was gelaufen ist.

Nun müssen wir noch den Hostnamen der WordPress-Installation anpassen. Dies geschieht direkt in der SQL-Datenbank. Da wir den Host später nochmals ändern müssen, ist dies bequemer als in der Docker-Config.

Zur Datenbank-Verbindung kann jeder gängige SQL-Client genutzt werden, etwa Sequel Pro auf dem Mac. Dort bei einer neuen Verbindung die eben erstellen Parameter eintragen und sich verbinden.

Verbindung zur SQL-Datenbank

In der Tabelle wp_options ändern wir nun die beiden Parameter siteurl und home auf http://10.10.10.10:10001 ab – wobei 10.10.10.10 der IP des NAS im Heimnetz und 10001 dem in der Docker-Konfiguration eingetragenen Port-80-Mapping entspricht. Beide Parameter könnten also bei euch anders sein, die IP ist es recht sicher.
Testweise können wir auch noch in die Tabelle wp_users schauen, dort sollte nun auch der oben konfigurierte, eigene Username zu sehen sein.

Die WordPress-SQL-Datenbank mit den Parametern siteurl und home

Nun kommt der spannende Moment — alles sollte funktionieren: Öffnet einen Browser und gebt http://10.10.10.10:10001 (oder was auch immer eure NAS-IP / Port ist) ein — Ihr solltet vom WordPress Standard-Theme begrüßt werden und einen Demo-Post sehen.

Auch der Admin-Bereich via http://10.10.10.10:10001/wp-admin sollte funktionieren und ihr müsstet in der Lage sein, euch einzuloggen. Möchtet ihr die WordPress-Installation nur im Heimnetz, ohne Zugriff aus dem Internet, nutzen, seid ihr an dieser Stelle schon fertig.

Solltet ihr statt der WordPress-Seite die Login-Seite des NAS / DSM sehen oder vielleicht auch gar nichts: Checkt nochmals alle Einstellungen und Port-Nummern.

Geschafft – Die Seite ist erreichbar und funktioniert!

2) Verbindung zur Außenwelt

Eine Website ist natürlich dazu gedacht, über das Internet erreichbar zu sein, deshalb widmen wir uns nun der externen Erreichbarkeit.
Voraussetzung hierfür ist, dass das NAS schon über das Internet erreichbar ist. Sollte dies nicht der Fall sein, müsst ihr die entsprechende Konfiguration mit EZ-Internet und einer Synology-Dyn-DNS-Adresse / Synology Account (Control Panel > External Access) durchführen. Sicherlich funktioniert dies auch mit anderen DnyDNS-Providern, getestet habe ich es aber via Synology. Letztere ist nämlich der Trick, der dafür sorgt, dass die Seite auch trotz wechselnder IP-Adresse eures Heim-Internet-Anschlusses von außen erreicht werden kann. Die DiskStation kümmert sich hier um das Update des nötigen DNS-Mappings.

Zusätzlich muss euer Router so konfiguriert sein, dass die Ports 80 (HTTP) und 443 (HTTPS) an die DiskStation durchgeleitet werden. Prinzipiell funktioniert es auch mit anderen Ports, diese müssten dann von Besuchern aber immer beim Besuchen der Seite mit eingegeben werden – nicht ideal.

Ist eure Diskstation über eine feste Adresse wie bspw http(s)://meinnas.myds.me erreichbar, ist es nur noch ein kleiner Aufwand, eure WordPress-Installation ebenfalls erreichbar zu machen. Synology erlaubt (undokumentiert) beliebige Subdomains des eigenen DynDNS-Namens für verschiedene Dienste zu nutzen. Diese Unterscheidung zwischen NAS-Oberfläche und Blog-Oberfläche mit anderer Subdomain machen wir uns via Reverse-Proxy zu Nutze. Dieser hat seit DSM 6 eine grafische Oberfläche (Control Panel > Application Portal > Reverse Proxy), sodass man keine Config-Dateien mehr von Hand bearbeiten muss. Wir legen dort nun einen Eintrag wie folgt an:

Der Reverse-Proxy-Eintrag zum Zugriff von außen

Der gewählte Name muss dabei eine Subdomain des schon vorhandenen DynDNS-Namens sein (natürlich müsst ihr hier wieder blog.meinnas.myds.me durch eure eigene Adresse austauschen). Im Zielbereich unten wird der Port, der für die Docker-HTTP-Kommunikation zuständig ist und auf Port 80 des Containers geleitet wird, eingetragen.

Nun müsst ihr auch wieder in der SQL-Datenbank siteurl und home auf http://blog.meinnas.myds.me ändern, diesmal ohne Portangabe (denn der Reverse Proxy übernimmt die Umwandlung).

Nach der Änderung könnt ihr die Funktion wieder im Browser überprüfen — bei Aufruf von http://blog.meinnas.myds.me solltet ihr wieder die WordPress-Seite sehen. Um sicher zu gehen, dass auch die Portweiterleitung des Routers funktioniert, empfiehlt es sich, die Seite auch von außerhalb eures Heimnetzwerks aufzurufen, beispielsweise vom Handy via Mobilfunknetz.

Sollte der Zugriff intern klappen, von außen aber nicht, sind die Portweiterleitungs-Regeln im Router nicht korrekt gesetzt. Sollte gar nichts klappen, überprüft nochmals die Reverse-Proxy-Einstellungen und achtet auf die korrekte Portnummer.

Es ist wichtig zu verstehen, was hier nun genau passiert. Externe Zugriffe auf eure Subdomain http://blog.meinnas.myds.me werden per DNS auf eure aktuell gültige Heimnetz-IP gesendet. Mittels der Port-Weiterleitungs-Regel im Router werden gültige Zugriffe auf Port 80 (HTTP) auf diese IP an die DiskStation im LAN weiter geschickt. Diese erkennt via Reverse Proxy anhand des Hostnamens, der aufgerufen werden soll (Subdomain), dass es sich nicht um einen Zugriff auf die DSM-Oberfläche, sondern das Blog handelt, und leitet den Request auf den entsprechenden Port (bspw 10001) um. Dieser wiederum wird in den Docker-Container auf Port 80 geschickt, wo der Request vom dort laufenden Apache beantwortet und wieder raus ins Internet geschickt wird ¹.

Solltet ihr happy mit einer Subdomain sein, dann könnt ihr Schritt 3) überspringen. Falls ihr natürlich eine eigene Domain haben wollt, lest weiter :)

3) Die eigene Domain

Richtig toll wird die eigene Website natürlich erst durch eine eigene Domain. Diese kann man sich bei einem beliebigen Anbieter für wenige Euros im Jahr mieten. Ihr ahnt es schon — auch die externe Domain lässt sich mit dem NAS verkuppeln. Hierzu ist es lediglich erforderlich, die DNS-Einstellungen der Domain bearbeiten zu können.
In der Regel lässt sich beim Eintrag für die Hauptdomain meinedomain.com bloß eine IP-Adresse und kein CNAME (Hostname) hinterlegen. Dies ist nicht weiter schlimm, denn wir können einfach eine Subdomain www.meinedomain.com anlegen. Für diese Subdomain muss der A-Record nun auf einen CNAME geändert werden, und zwar eure DynDNS-Subdomain http://blog.meinnas.myds.me (es sollte auch ohne blog. funktionieren).

Nun sollte sich bei einem PING an beide Adressen (einmal meinedomain.com und www.meinedomain.com) ein unterschiedliches Verhalten² zeigen:

Ping auf die Hauptdomain und www.-Subdomain

Die reine Domain liegt nach wie vor beim Hoster (hier die IP 74.208.xxx.xxx), die Subdomain www. wird aber zum NAS weitergeleitet und der Ping wird von dort beantwortet (die IP 172.249.xxx.xxx). Damit nun auch Aufrufe auf meinedomain.com auf dem Blog landen, muss man für diese Adresse noch eine permanente Umleitung zur www.-Subdomain einrichten. Dies funktioniert je nach Webhoster unterschiedlich, ist aber in der Regel problemlos möglich.

Zwei Einstellungen fehlen noch zum Glück:

• Ein Reverse-Proxy-Eintrag für die neue Domain. Ihr könnt hier den aus Schritt 2 genutzten Eintrag abändern und den Domainnamen statt der blog.-Subdomain eintragen.
• Die Anpassung des WordPress-Hosts: siteurl und home müssen in der Datenbank auf http://www.meinedomain.com geändert werden.

Auch hier nun der Ausflug in den Browser zum Testen – am besten ebenfalls von extern testen.

4) SSL, bitte!

Dank Let’s Encrypt ist es heutzutage so einfach wie nie, ein valides SSL-Zertifikat für die eigene Website zu erhalten, und das auch noch kostenlos. Die Einrichtung ist normalerweise schon recht einfach, aber mit DSM geht es noch schneller. Durch die obige Konfiguration mit dem Reverse Proxy lassen sich auch mehrere Zertifikate für verschiedene Domains / Dienste korrekt einbinden. Das heißt, ihr könnt auch mehrere Websites oder eure private Website und dazu das NAS mit eigenen Zertifikaten absichern.

SSL ist kein Muss und die Website funktioniert auch ohne — ich rate euch aber unbedingt, das Zertifikat zu installieren, zumal das in ein paar Minuten getan ist und es eigentlich nur Vorteile bietet.

Öffnet hierzu den Bereich »Security« im »Control Panel«. Setzt im Bereich »Advanced« einen Haken bei »Enable HTTP Compression« und wählt die »Modern Compatibility« für die TLS/SSL Cipher Suites aus. Mit dieser Einstellung schickt die DSM HTTP-Daten komprimiert übers Netz und blockiert außerdem ältere, weniger sichere Clients und aktiviert modernere Verschlüsselungsmethoden bei den Zertifikaten. ³

Schaut dann anschließend im Reiter »Certificate« rein und fügt ein neues Zertifikat hinzu. Im Wizard gebt ihr an, ein neues Zerfikat von Let’s Encrypt erhalten zu wollen. Als Name bietet sich euer Domainname an, den ihr auch im nächsten Schritt zusammen mit eurer E-Mail-Adresse nochmals eingeben müsst. Das Feld »Subject Alternative Name« könnt ihr leer lassen, sofern ihr nicht weitere Subdomains absichern wollt. Mit einem Klick auf »Apply« wird das Zertifikat generiert. Hierzu muss eure Domain aber bereits auf dem DSM erreichbar sein, sonst funktioniert dies nicht.

Ein neues Zertifikat für die externe Domain

Im »Configure«-Schirm müsst ihr nun eurer externen Domain noch das korrekte Zertifikat zuweisen.

Zuweisung des Zertifikats zur Domain

Damit das Zertifikat nun auch vom Reverse Proxy genutzt und ausgeliefert wird, muss die Konfiguration hier auch noch geändert werden. Hier ist wichtig zu verstehen, dass das Zertifikat gar nicht im Docker-Container installiert wird, sondern quasi vom Reverse-Proxy dem Traffic übergestülpt wird. ⁴

Öffnet also die Reverse-Proxy-Configuration und ändert den bestehenden Eintrag wie folgt ab:

Der Reverse-Proxy-Eintrag für die SSL-Domain

Ändert das Protokoll von HTTP auf HTTPS ab und tragt euren Domainnamen (hier wie immer beispielhaft) ein. Wählt außerdem 443 als Port und hakt HSTS und HTTP/2 an. Die Ziel-Konfiguration könnt ihr bestehen lassen, hier bitte nicht HTTPS wählen.

Mittels HSTS und der strikten Cipher-Suite verdient sich die SSL-Konfiguration ein glattes A+ bei SSL Labs – perfekt.

Nun solltet ihr in der Lage sein, auf eure eigene Website mittels https://deinedomain.com zugreifen zu können und es sollte auch keine Zertifikatswarnung angezeigt werden. Es ist möglich, dass der Browser über Mixed Content meckert und die CSS-Dateien nicht lädt. Dies liegt daran, dass WordPress noch nichts über die SSL-Änderung erfahren hat.

Daher empfiehlt es sich, ein Plugin wie beispielsweise Really Simple SSL zu installieren – das sorgt dafür. Ironischerweise hat bei mir die Änderung von siteurl und home auf https:// in der SQL-Datenbank zu Problemen geführt – mit dem Plugin und unveränderter Datenbank-Config hat aber alles geklappt.

Nun sollte die Seite stehen und ein grünes Schloss im Browser erscheinen.

5) Feintuning und kleine Fehler

Die Website funktioniert nun ohne Probleme — fast. Das Docker-Image ist sehr minimalistisch und enthält daher einige Zusatzsoftware nicht, die vielleicht benötigt wird. Sichtbar wird dies unter anderem daran, dass die Permalinks in WordPress nicht funktionieren, weil das Apache-Modul mod_rewrite nicht aktiviert / konfiguriert ist. Um dies nachzuholen und bei der Gelegenheit noch weitere Sachen zu optimieren, begeben wir uns wieder ins Terminal. Keine dieser Änderungen ist zwingend notwendig, aber sie schaden auch nicht :)

Das Terminal kann wieder, wie oben schon geschrieben, via DSM als virtuelles Terminal geöffnet werden. Es ist auch möglich, sich mit einem nativen Terminal direkt in den Container zu verbinden. Hierzu müsst ihr euch erst einmal auf das NAS via SSH verbinden (etwa per ssh -l deinuser 10.10.10.10 wobei ihr den User und die IP natürlich ersetzen müsst⁵. Dann verbindet ihr euch im zweiten Schritt mit dem Docker-Container:

sudo docker exec -i -t deinedomain.com /bin/bash wobei deinedomain.com hier für den Containernamen steht.

Nun solltet ihr euch wieder als root im Docker-Container befinden. Alle nachfolgenden Befehle sind im Docker-Container (und keinesfalls auf dem Host-NAS!) auszuführen.

Um mod_rewrite zu aktivieren, zuerst

sudo a2enmod rewrite

eingeben. Dann mittels eines Editors (vi ist schon installiert, nano muss installiert werden) die Datei /etc/apache2/apache2.conf editieren und im Bereich /var/www/ den Wert AllowOverride auf FileInfo setzen — siehe Screenshot.

Per vi:
vi /etc/apache2/apache2.conf

Oder per nano (finde ich persönlich viel benutzerfreundlicher):

sudo apt-get install nano -y (nano ohne Nachfrage installieren)
nano /etc/apache2/apache2.conf (Datei bearbeiten)

Editieren der Apache-Config-Datei via nano

Anschließend via sudo service apache2 restart Apache neu starten. Achtung: Hierbei fliegt ihr aus der Shell des Containers raus, ihr müsst euch anschließend neu verbinden. Die WordPress-Permalinks funktionieren nun.

Es gibt noch weitere Sachen, die wir via Terminal erledigen können:

Überprüfen, ob es neue Softwareupdates gibt…
apt-get update

… und diese dann auch installieren (-y erspart euch die Rückfragen)
apt-get upgrade -y

Das dauert eine Weile.

Anschließend lohnt sich sich, die PHP-Configuration einmal genauer unter die Lupe zu nehmen.
Die PHP-Version lässt sich auch direkt via php -v auslesen, detaillierter ist aber eine phpinfo-Datei, die wir wie folgt anlegen können:

nano /var/www/html/phpinfo.php

Diese wird mit dem Inhalt <php phpinfo() ?> befüllt und dann abgespeichert. Nun kann via deinedomain.de/phpinfo.php die gesamte Konfiguration betrachtet werden. Wir stellen schnell fest, dass das nicht mehr ganz taufrische PHP 5.x installiert ist. Dieses können wir in wenigen Handgriffen durch ein frisches PHP 7.1 ersetzen. Nochmals, das ist kein Muss, aber wo wir schon dabei sind…

Um PHP 7.1 zu installieren, müssen wir Ubuntu ein neues Repository bekannt machen. Hierzu müssen zunächst weitere Tools installiert werden:

sudo apt-get install python-software-properties software-properties-common -y

Dann das Repo ppa:ondrej hinzufügen:

sudo LC_ALL=C.UTF-8 add-apt-repository ppa:ondrej/php

und anschließend alles aktualisieren:

sudo apt-get update

Weiterhin das alte PHP5 deinstallieren…

sudo apt-get purge php5-common -y

…und PHP 7.1 nebst ein paar Zusatzfunktionen installieren:

sudo apt-get install php7.1 php7.1-fpm php7.1-curl php7.1-mysql php7.1-json -y

Dann muss PHP 7.1 noch mit Apache verbunden und aktiviert werden, dies klappt via

sudo apt install php libapache2-mod-php -y und

sudo a2enmod php7.1

Im Anschluss räumen wir noch auf und bringen den Müll raus, pardon, löschen die nicht mehr genutzten Pakete:

sudo apt-get --purge autoremove -y

Zu guter Letzt muss Apache wieder neu gestartet werden. Denkt daran, dass euch das wieder aus der Shell wirft.

sudo service apache2 restart

Nach neu verbinden sollte via php -v nun PHP 7.1 (oder neuer) sichtbar sein, in meinem Fall war es PHP 7.1.7-1+ubuntu14.04.1+deb.sury.org+1.

So schön die neueste Version auch ist, das sollte nicht unbedingt jeder auf die Nase gebunden bekommen. Deshalb löschen wir nun die phpinfo-Datei auch wieder (sofern Ihr sie nicht noch anderweitig braucht):

rm /var/www/html/phpinfo.php

Sicherlich gibt es noch andere Rädchen, an denen man drehen kann, aber diese Einstellungen und Aktualisierungen sind meiner Meinung nach die Wichtigsten.

Wie bereits oben geschrieben, funktioniert sendmail nicht. Keine Katastrophe, aber WordPress kann so leider keine E-Mails versenden. Ich habe mehrere Sachen erfolglos probiert. Solltet ihr eine Lösung haben — immer her damit.

6) Backup und Wiederherstellung

Ein toller Vorteil von Docker ist, dass man komplette Container in eine Backup-Datei wegsichern kann – und das solltet ihr auch tun. Dies funktioniert via DSM sehr einfach, indem ihr euren Container in der Übersicht markiert und ihn via Settings > Export in eine Datei schreibt. Dieser Vorgang funktioniert auch bei laufendem Container und dauert ca 10 Minuten. Die Backup-Datei wird bei der hier besprochenen Initial-Konfiguration etwa 80-100MB groß. Genau so einfach lässt sich der Container auch wiederherstellen — sicherheitshalber solltet ihr das einmal durchspielen.

Backup des Containers

Ebenfalls könnt ihr nun den oben eingerichteten Austauschorder wp_2_nas zum Leben erwecken. Er kann von einem WordPress-Backup-Plugin eurer Wahl als Ziel genutzt werden, da er um upload-Pfad von WordPress liegt. BackWPUp ist beispielsweise ein Plugin, das Backups von der kompletten Konfiguration, Daten und Datenbank erstellen kann und diese in den Ordner (und damit ja dann direkt auf euer Host-NAS) legen kann.

7) Testen und Freuen

Ihr solltet nun zum Abschluss nochmals alles testen und die Website aus verschiedenen Browsern und Netzen aufrufen. Grundsätzlich sollte aber durch die Schritt-für-Schritt-Anleitung nichts schief gegangen sein. Falls doch, schreibt mir einen Kommentar…

Noch eine letzte Warnung: Nutzt die im DSM vorhandenen Features wie den Sicherheitsberater, um sicher zu stellen, dass das System immer auf dem neuesten Stand ist und ihr keine Dienste im Internet bereit stellt, die dort nichts zu suchen haben (SQL, SSH etc). Nutzt außerdem einen von admin abweichenden Benutzernamen, die »automatische Blockierung« und die Firewall im DSM. So toll ein eigenes NAS auch ist — fremde Gäste sollten lieber draußen bleiben.

Um die in den anderen Blogbeiträgen geteilten Rezepte backen zu können, brauchst du einen aktiven, eigenen Sauerteig-Starter (auch Anstellgut genannt).

In Deutschland wird Sauerteig oft mit Roggensauerteig gleich gesetzt, dies ist allerdings nicht zwanghaft der Fall. Ich finde Weizen-Sauerteig angenehmer, weil er nicht so schwer ist und auch Broten, die man sonst nicht als Sauerteig-Brote backen würde, eine tolle Geschmacksnote gibt und sie bekömmlicher macht.

Sauerteig besteht im Wesentlichen aus Milchsäurebakterien und Hefepilzen. Es gibt mehrere Methoden, wie man Sauerteig selbst beginnen kann und es gibt dutzende Anleitungen dazu im Internet. Die einfachste Methode ist mit Sicherheit, wenn man jemanden kennt, der selbst Sauerteig züchtet: Fragt ihn einfach, ob ihr etwas abbekommt.

Ich habe meinen Sauerteig-Starter hier in den USA von King Arthur Flour bestellt und dann angezüchtet, in Deutschland gibt es ähnliches etwa bei Spiegelhauer (ohne Garantie, nicht getestet)

Sauerteig ist ein lebender Organismus und muss daher gefüttert werden, um am leben zu bleiben. Hierzu verwendet man entweder einen Teil des Sauerteigs und fügt Wasser und Mehl dazu oder man wirft einen Teil des alten Teiges weg. Generell muss der Teig bei Raumtemperatur alle 12 Stunden gefüttert werden, im Kühlschrank hält er sich 1-2 Wochen ohne Fütterung. Sollte er einmal etwas länger stehen und sich an der Oberfläche eine klare Flüssigkeit abgesetzt haben — keine Sorge, die kannst du unterrühren. Solange sich kein Schimmel bildet, ist alles in Ordnung.

Aktiver Sauerteig nach ca 6 Stunden

Von alten 12 Teilen (12 oz) Sauerteig wirft man also 8 Teile weg (oder gibt sie an Freunde) und fügt 4 Teile Wasser und 4 Teile Mehl hinzu und verrührt das Ganze. Nach ein paar Stunden sieht man an der Blasenbildung, dass der Sauerteig wieder voll einsatzbereit ist.

Wir leben seit zwei Jahren in den USA und dort gibt es leider nicht besonders oft Brot, wie man es aus Deutschland kennt. Ich habe mich daher entschlossen, selbst zu backen und habe dieses Rezept für Körnerbrot entwickelt.

Das Resultat sind zwei wunderbare Körnerbrote mit krosser, brauner Kruste. Frisch aus dem Ofen, braucht man eigentlich nicht mehr als ein Stück Butter, um sie zu genießen. Durch den Einsatz von Sauerteig sind die Brote sehr bekömmlich und haben einen tollen Geschmack, sie halten außerdem

länger frisch: Die Brote halten sich ohne Kühlung locker 4-5 Tage ohne auszutrocknen (ich stelle Sie dazu auf die Schnittfläche). Die Brote lassen sich aber auch sehr gut einfrieren. Nach dem Auftauen toastet man die Scheiben — fertig.

Ich wünsche dir viel Freude beim Nachbacken und freue mich über Kommentare oder Fotos.

Du brauchst für die Grundmischung (zwei Brote, jeweils ca 800g):

• 590g (21oz) Weizenmehl (Typ 550 ist in Ordnung)
• 140g (5oz) dunkles Roggenmehl
• 10g Trockenhefe ¹
• 225g (8oz) Sauerteig-Starter, gefüttert (siehe „Sauerteig„)
• 30g Gerstenmalz (enzymaktiv / distatisch)²
• 25g Salz
• 20g Zucker
• 350ml Wasser, lauwarm
• 1 Ei ³

Du brauchst für die Körnermischung:

• 30g Kürbiskerne, geröstet, ungesalzen
• 50g Haselnüsse, ganz, mit Schale
• 30g Haferflocken, kernig
• 25g Sonnenblumenkerne, geröstet, ungesalzen
• 20g Flachssamen (Leinsamen)
• 10g Flachs, gemahlen ⁴

Du brauchst für das Topping⁵:

• Eine Handvoll Kürbiskerne
• Eine Handvoll Sonnenblumenkerne
• Eine Handvoll Haferflocken

Du brauchst außerdem:

• Zwei Gärkörbchen / Brotformen
• Ein Backblech
• Ca fünf Stunden Zeit

Vorbereitung

Zunächst Weizenmehl, Roggenmehl, Hefe, Sauerteig-Starter, Malz, Salz, Zucker, Ei und das lauwarme Wasser in einer großen Schlüssel mischen. Diese mit einer Hand festhalten und mit der anderen Hand den Teig kneten und dabei immer wieder von oben nach unten und von links nach rechts „überfalten“, sodass sich alles gut mischt und ein homogener, glatter Teig entsteht. Der Teig darf nun noch leicht klebrig sein, da die Körner noch dazu kommen.

Im zweiten Schritt alle Bestandteile der Körnermischung in den Teig einarbeiten. Dies geschieht separat und nicht direkt am Anfang, um nicht zu viele Körner und Kerne kaputt zu drücken. Auch hier darauf achten, dass alles gleichmäßig verteilt ist und den Teig nach gleicher Technik verkneten. Der Teig sollte zum Schluss nun nicht mehr klebrig sein und sich leicht von den Händen lösen lassen.

Ruhezeit

Die Teigkugel nun abgedeckt in einer Schüssel an einem warmen Ort (aber nicht über 35 Grad) etwa 2 Stunden gehen lassen. Sie sollte ihr Volumen in etwa verdoppeln.

Die Teigkugel nun behutsam aus der Schüssel lösen und in zwei Teile zerteilen und längliche Würste formen (die in die Körbchen passen). Den Teig nun rundwirken⁶, aber nach Möglichkeit nicht nochmals komplett durch kneten und nur behutsam formen / strecken.

Der Brotlaib, nachdem er in Körnern eingerollt wurde

Auf einem mit Backpapier ausgelegten Rost oder Blech die Mischung für das Topping verteilen. Die Würste, einer nach dem anderen, nun mit etwas Wasser einreiben, auch die Enden nicht vergessen. Die Teigwürste dann kräftig über die Topping-Mischung rollen, bis alles außen mit Kernen bedeckt ist. Die Laibe dann vorsichtig in die Gärkörbchen legen. Die sehen zu klein aus, passen aber.

Die Brotlaibe in den Gärkörbchen zu Beginn der 2. Gehzeit

Nun die Laibe wieder abgedeckt 2-4 Stunden⁷ in den Gärkörbchen mit Tuch abgedeckt gehen lassen, sie sollten zum Schluss etwa so hoch wie die Körbchen sein.

Backen

Den Backofen auf 450F / 230 Grad C vorheizen.

Die Gärkörbchen nun vorsichtig auf das Backblech mit Backpapier umdrehen, die Brote sollten von alleine heraus fallen. Falls nicht, einfach die Körben etwas anheben und warten⁸.

Beide Laibe ca 2cm tief der Länge nach einschneiden.

Das fertig gebackene Brot

Nach ca 15 Minuten die Hitze auf 400F / 200 Grad C herunter drehen. Während des gesamten Backvorgangs die Ofentüre nach Möglichkeit geschlossen halten und die Bräunung nur durch das Ofenfenster verfolgen. Die letzten fünf Minuten die Türe einen Spalt weit öffnen, um den noch vorhandenen Dunst (Schwaden) abzulassen.

Brote mindestens 30 Minuten abkühlen lassen und anschneiden… Guten Appetit!

Alternativ kannst du auch ein reines Sauerteigbrot ohne Körner backen: Hierzu die komplette Körnermischung einfach weg lassen, die Laibe nicht in Körnern einrollen und 10g mehr Mehl benutzen.

Neben meinen Körnerbrot backe ich eine zweite Variante ganz besonders gerne: Ein reines Sauerteigbrot. Das Besondere hierbei ist, dass das Brot nur ganz wenige Zutaten hat und auch ohne Hefe auskommt — allerdings braucht es mehr Zeit und Ruhe.

Ich wünsche dir viel Freude beim Nachbacken und freue mich über Kommentare oder Fotos.

Du brauchst für zwei Brote, jeweils ca 800g:

• 600g Weizenmehl (Typ 550 ist in Ordnung)
• 240g (8 ½oz) Sauerteig-Starter, gefüttert (siehe „Sauerteig„)
• 16g Salz
• 340ml Wasser, lauwarm

Das Brot lässt sich leicht variieren, indem man am zweiten Tag noch eine mediterrane Extrazutat hinzugibt. Hier bietet sich folgendes an:
a) 50g gehackte Wahlnüsse oder
b) 10g Olivenöl, 7g Kümmel und + 25g Mehl oder
c) 15 Gramm Rosmarin und etwas Fleur de Sel (drüber streuen bevor es in den Ofen geht) oder
d) 50g Kalamata Oliven (abgetrocknet)

Vorbereitung, 1. Tag

Den Starter mit 360g Mehl und dem kompletten Wasser in eine Schüssel¹ geben und diese Zutaten dann eine Minute mit einem Löffel schlagen und verrühren. Den (sehr sehr wässrigen) Teig so ca 4 Stunden an einem warmen Ort gehen lassen.
Den Teig dann abgedeckt für 12-24 Stunden in den Kühlschrank stellen.

2. Gehen am 2. Tag

Den Teig aus dem Kühlschrank nehmen und eine Stunde warm werden lassen. Nun die 240g Mehl (den Rest) und das Salz unterrühren und kräftig von Hand verkneten. Die Konsistenz des Teiges sollte nun so sein, dass nichts mehr an den Händen klebt. Den Teig nun zu einer Kugel formen und eine Stunde ruhen lassen.

Teigmassage

Der nun folgende Teil dauert zwischen ca 3-4 Stunden, je nach Temperatur und Gehfreudigkeit des Teiges. Prinzipiell gilt es, den Teig jede Stunde einmal rundzuwirken² und ihn dann für eine weitere Stunde ruhen zu lassen. Keinesfalls den Teig komplett durchkneten.

Hierbei kannst du (hoffentlich) bei jedem Mal eine deutliche Veränderung feststellen: Der Teig wird voluminöser und schlägt Blasen, die auch sichtbar werden. Nach ca 3-4 Stunden ist der Teig sehr sehr locker geworden.

Den Teig dann in zwei Hälften teilen und „in“ die Bruchstelle rundwirken, sodass diese etwas feuchtere Stelle des Teiges nicht offen liegt.

Beide Laibe in zwei gut gemehlte Gärkörbchen / Brotformen legen und eine weitere Stunde gehen lassen.

Backen

Den Backofen auf 400F / 200 Grad C vorheizen.

Die Gärkörbchen nun vorsichtig auf das Backblech mit Backpapier umdrehen, die Brote sollten von alleine heraus fallen. Falls nicht, einfach die Körben etwas anheben und warten³.

Die Brote, frisch aus dem Ofen (Hier die Kümmel-Variante)

Beide Laibe ca 2cm tief der Länge nach einschneiden.

Die Brote in den Ofen schieben und sofort ein halbes Glas Wasser (ca 150ml) auf den Boden des Ofens⁴ schütten. Das Wasser sollte sofort verdampfen und sorgt für eine knusprige Kruste. Die Gesamtbackzeit ab nun beträgt 28-32 Minuten (je nach gewünschter Bräune).

Die letzten fünf Minuten die Türe einen Spalt weit öffnen, um den noch vorhandenen Dunst (Schwaden) abzulassen.

Brote mindestens 30 Minuten abkühlen lassen und anschneiden… Guten Appetit!

1. Lieber eine größere Schüssel nehmen, weil noch weiteres Mehl dazu kommt und der Teig auch gehen muss ↩
2. etwa so ↩
3. Falls die Laibe richtig in den Körbchen fest kleben, beim nächsten Mal mehr Mehl verwenden ↩
4. Hier streiten sich die Gelehrten. Einige sagen, man solle das Wasser auf den Boden schütten, andere empfehlen ein Backblech mit Wasser darauf… Ausprobieren! ↩

Als ich mit der Recherche um das Thema angefangen habe, erschein mir ArchiveBox zunächst als die bessere Lösung, nach einiger Zeit ist dieser Gedanke aber mehr und mehr in Richtung Wallabag umgeschwenkt. Dennoch bietet auch ArchiveBox ein nicht zu unterschätzendes Werkzeug, dass genauere Betrachtung verdient.

ArchiveBox ist an das Internet Archive angelehnt und dient, wie der Name schon sagt, dem Archivieren von Webinhalten. Es ist allerdings nicht auf die Verwaltung von großen Textmengen optimiert und kann beispielsweise nicht mit Tags umgehen. Daher fiel es funktionsmäßig als erstes Tool in der Kette aus.
Dennoch kann es gute Gründe geben, Websites mittels ArchiveBox zu sichern: Die Software ist in der Lage, eine Website auf vielerlei Arten zu sichern: Als Screenshot, Volltext-HTML (jedoch keine Reduzierung auf den wesentlichen Textinhalt — aber das erledigt ja Wallabag) oder PDF. Das Internet Archive wird ebenfalls mit der Bitte, die Seite zu sichern, angepingt. Auch ein YouTube-Downloader (youtube-dl) ist vorhanden.

Das Archiv der all dieser Seiten wird in einem Ordner (Idealerweise von Docker ins auf’s NAS gemappt) angelegt, inklusive einem durchsuchbaren Index. All dies ist so gestaltet, dass es auch „offline“ funktioniert: Es braucht (im Gegensatz zu Wallabag) keinen laufenden Server, um das Archiv zu begutachten. Da der Index via HTML / JS funktioniert, läuft er in jedem modernen Browser. Selbst wenn dies nicht der Fall sein sollte: Alle gesicherten Inhalte liegen leicht zu erreichen im Klartext, mit Domain im Dateisystem. Hier können sie auch leicht von systemweiten Suchfunktionen gefunden werden.

Das Archiv ist also notfalls versendbar oder kann kalt archiviert werden: PDF-Dateien, JPEGs und HTML werden sich wohl auch noch in Jahrzehnten öffnen lassen.

Das Interface von ArchiveBox mit den gespeicherten Datentypen

Vorsichtig sollte man allerdings insbesondere beim HTML der Websites sein, denn: Das lebt noch. Bei der Menge und Art und Sachen, die mittlerweile via Jasascript auf Websites (nach)geladen werden, ist nicht auszuschließen, da auch noch ein Tracker oder Werbung nachkommt. In Kombination mit Pi-Hole sollte das meiste allerdings schon von vorne herein draußen gehalten werden.

Ich habe ArchiveBox einfach via öffentlichem RSS-Feed mit Wallabag verknüpft. Alles, was ich nochmals „bombensicher“ archivieren möchte, landet via Hashtag abx in ArchiveBox und wird von dort in mein normales Backup weggesichert.

Es kommt natürlich immer auf den Anwendungszweck an. Wer vornehmlich Texte liest, kann ArchiveBox wohl außen vor lassen, ich könnte mir aber vorstellen, dass beispielsweise Journalisten, Wissenschaftler, Historiker oder Anwälte Verwendung für ArchiveBox haben können.

ArchiveBox ist leider nicht im Docker-Hub zu finden, also muss man einen kleinem Klimmzug machen, um die Software auf dem NAS installieren zu können. Die Doku gibt’s bei Github. Leider klappt der dort vorgeschlagene Weg via git clone nicht, da auf dem NAS standardmäßig kein Git installiert ist. Falls doch – kein Problem, dann bitte machen. Falls nicht, hier ist der manuelle Weg.

Wir legen uns einen Ordner mit Unterordner an und laden dann das Repository herunter:

mkdir /volume1/docker/ArchiveBox
cd /volume1/docker/ArchiveBox
wget https://github.com/pirate/archivebox/archive/master.zip


Anschließend wird das Archiv entpackt und wieder entfernt:

7z x master.zip
rm master.zip

Dann muss noch ein Unterordner erstellt werden:

cd ArchiveBox-master/
mkdir data && chmod 777 data

Nun kann die automatische Installation der Container via docker-compose beginnen, da eine entsprechende Konfigurationsdatei vorhanden ist. Los geht’s via docker-compose up -d: Daten werden geladen, installiert und Container erzeugt – idealerweise geht hier alles automatisch und am Schluss steht man mit zwei fertigen Containern da, die sich dann in der Synology-UI finden lassen. Das ganze hat bei mir rund 20 Minuten gedauert¹.

Nun steht ArchiveBox unter dem Port 8098 zur Verfügung – hat allerdings außer einem Testlink nichts gespeichert. Wer möchte, kann ArchiveBox auch via Reverse-Proxy im Internet verfügbar machen, ich habe allerdings davon abgesehen, da ich ArchivBox nur als „Cold Storage“ für einige bestimmte Sachen nutze und von Unterwegs nicht unbedingt darauf zugreifen können muss².
Der Archiv-Output steht nun ebenfalls im Verzeichnis /volume1/docker/ArchiveBox/data zur Verfügung und können mit jedem Browser angesehen werden. Diesen Ordner kann man auch auf einen anderen Pfad umlegen, wenn man ihn beispielsweise in ein Backup einschließen möchte.

Neue Links kann man nun wie folgt hinzufügen:
echo "https://example.com" | docker-compose exec -T ArchiveBox /bin/archive

Einen RSS-Feed, beispielsweise aus Wallabag zu einem bestimmten Tag, übergibt man per

docker-compose exec ArchiveBox /bin/archive https://example.com/some/feed.rss

Dies kann man auch wieder per Cron automatisieren und so den RSS-Feed automatisiert parsen und Inhalte sichern lassen.

ArchiveBox kann leider nicht hinter Paywalls schauen. Es gibt jedoch die Möglichkeit, Cookies manuell zu hinterlegen. Dies könnte bei einigen einfachen Authentifizierungsmechanismen funktionieren, bei neueren Standards ist dies allerdings nicht garantiert.
Ich halte es für mein eigenes Archiv auch nicht für empfehlenswert, jedesmal die große Hafenrundfahrt mit Screenshot, PDF, HTML etc zu sichern – bei den meisten Sachen, die ich speichere, handelt es sich um Texte, für die im Notfall selbst die Wallabag-Textversion vollkommen ausreichend wäre. Aber dennoch ist ArchiveBox ein Tool, was eine Lücke besetzt und seinen klaren Einsatzzweck hat.

Die folgenden Themen werden in der Wallabag-Artikelserie behandelt:
Einleitung —  Auf Vorrat gespeichert: Das eigene Web-Archiv auf dem NAS
Teil 1: Was kann Wallabag?
Teil 2: Wallabag via Docker auf Synology NAS
Teil 3: Wallabag-Tuning
Teil 4: Wallabag und Paywalls
Teil 5: Wallabag-Backup und Versionsupdates
Teil 6: RSS-Import zu Wallabag
Teil 7: Wallabag und eReader
Teil 8: Archivebox und Wallabag

Vielleser schätzen einen e-Book-Reader ob seiner Leichtigkeit – man kann quasi unbegrenzt Bücher mitnehmen. Und da liegt es doch auch nahe, sich Artikel aus Wallabag auf den e-Book-Reader zu beamen.

Da ich einen Amazon Kindle habe, bin ich hier aktiv geworden und habe mich um eine Einbindung gekümmert. Der Weg via ePub für andere Reader dürfte ähnlich sein.

Das Web-Interface des Kindle Consumers

Am besten richtet man einen eigenen E-Mail-Account für dieses Versenden ein – so läuft man nicht Gefahr, dass Daten zum eigenen E-Mail-Konto permanent irgendwo gespeichert werden – selbst wenn es das eigene NAS ist. Nicht vergessen, diesen Account auch als berechtigten Absender im Kindle-Portal einzugeben.

Das Image findet sich unter dem Namen wallabag-kindle-consumer im Docker-Hub und kann mit einem Klick geladen werden, unbedingt auf den korrekten Author janlo achten!

Nachdem das Image heruntergeladen wurde, müssen beim erstmaligen Erstellen leider viele Umgebungsvariablen mit der Hand erstellt werden. Die entsprechenden Defaults sind in der Dokumentation zu finden, den eigenen Mail-Server, -Passwort etc muss man natürlich selbst ergänzen.
Beim ersten Start des Containers muss noch erstmalig die Datenbank initialisiert werden.
Hierzu in den Container verbinden:
docker exec -i -t wallabag-kindle-consumer /bin/sh

und dann diesen Befehl ausführen:
./service.py --create_db --env
Zur Sicherheit nun auch nochmals den Log checken, um eventuelle Fehler zu finden.
Nachdem der Container gestartet wurde, läuft der Service automatisch. Er muss nicht nochmals via ./service.py --refresher --consumer --interface gestartet werden.
Der Container bietet ebenfalls eine Konfigurationsoberfläche für den Wallabag-User und -Passwort bereit. Das Interface dient ebenfalls zum manuellen Aktualisieren des Tokens, falls die automatische Aktualisierung mal nicht funktionieren sollte — was das Erliegen der Sendefunktion zur Folge hat.

Warum sich in diesem Interface nicht all die Sachen, die per Umgebungsvariable eingegeben werden müssen, konfigurieren lassen, erschließt sich mir allerdings nicht.

Im Log zeigt sich nun im Detail, was passiert. In meinem Fall leider auch ab und zu eine Fehlermeldung meines E-Mail-Providers, der zu viele parallele Logins aus Sicherheitsgründen nicht erlaubt. Hier muss Jan vielleicht noch nachbessern, denn in diesem Fall gehen die Artikel aktuell „verloren“ – der Tag wird entfernt, die E-Mail kann aber nicht versendet werden. Das verhindert zwar Endlosschleifen, aber der Artikel ist weg. Dies kann man natürlich dadurch umgehen, pro Versendezyklus nur einen Artikel zu taggen, aber wirklich praktikabel ist das natürlich nicht. Da dies aber auf das spezielle Setup meines Mailservers zurückzuführen ist, sehe ich dies nicht als generelles Problem an.

Der korrekte Log-Output sieht beispielsweise so aus:

[2019-02-10 03:40:03.889539] INFO: wallabag_kindle_consumer.config: read config from file config.ini
[2019-02-10 03:40:03.890119] WARNING: wallabag_kindle_consumer.config: Config file config.ini does not exist
[2019-02-10 03:40:03.890407] INFO: wallabag_kindle_consumer.config: Read config from environment
[2019-02-10 03:40:03.891637] INFO: kindle-consumer: Create Refresher
[2019-02-10 03:40:03.915713] INFO: kindle-consumer: Create Consumer
[2019-02-10 03:40:03.918007] INFO: kindle-consumer: Create Interface
[2019-02-10 03:40:34.937841] INFO: wallabag_kindle_consumer.consumer: Schedule job to send entry 11774
[2019-02-10 03:40:36.198120] INFO: wallabag_kindle_consumer.wallabag: Removed tag kindle from article 11774 of user martin
[2019-02-10 03:40:38.100508] INFO: wallabag_kindle_consumer.consumer: Process export for job 11774 (mobi)
[2019-02-10 03:40:41.594179] INFO: wallabag_kindle_consumer.sender: Mail with article 11774 in format mobi sent to xxx@kindle.com


Die Artikel stehen auf dem Kindle unmittelbar zum Download bereit. Leider werden keine Bilder konvertiert und die Formatierung ist teilweise auch fehlerhaft, insbesondere, wenn im Originalartikel komplexes HTML verwendet wird – ob dies am generellen eBook-Export oder an Jan’s Software, weiss ich nicht. Für den grundlegenden Anwendungszweck taugt die Software aber: Normale Texte werden anständig konvertiert und können am Kindle einwandfrei gelesen werden.
Was ich allerdings auch hier vermisse, ist eine Markierung als gelesen. Dies klappte bei Instapaper immer toll: Unter den Artikeln war ein Link, dessen Aufruf den Artikel dann wegsortiert hat.

Die folgenden Themen werden in der Wallabag-Artikelserie behandelt:
Einleitung —  Auf Vorrat gespeichert: Das eigene Web-Archiv auf dem NAS
Teil 1: Was kann Wallabag?
Teil 2: Wallabag via Docker auf Synology NAS
Teil 3: Wallabag-Tuning
Teil 4: Wallabag und Paywalls
Teil 5: Wallabag-Backup und Versionsupdates
Teil 6: RSS-Import zu Wallabag
Teil 7: Wallabag und eReader
Teil 8: Archivebox und Wallabag

Es gibt sicherlicht gute Gründe, warum die Wallabag-Macher von Haus aus keinen RSS-Import vorgesehen haben. Andererseits gibt es genau so viele gute Gründe, dies doch zu tun. Je nach Setup möchte man beispielsweise alle Artikel einer Nachrichtenseite zu einem bestimmten Thema abonnieren und dies automatisch zu Wallabag hinzufügen. Ein anderer Usecase ist es, die eigenen Twitter-Postings zu archivieren. Einen offiziellen Twitter-RSS-Feed gibt es nicht mehr, aber es gibt Alternativen.

Es gibt ein Python-Script, was diese Aufgabe für einen oder mehrere RSS-Feeds übernehmen kann: Jeder Eintrag des Feeds wird als neuer Link zu Wallabag hinzugefügt. Da Wallabag selbst in einem Docker-Container läuft, ist es ratsam, dieses Script ebenfalls in einen Container auszulagern, alleine schon deshalb, weil man auf seinem Host-System so wenig Pakete wie möglich installieren will, da es sonst zu Versionskonflikten installierter Software kommen kann.

Das Script ist simpel und braucht nicht viel – deshalb können wir das offizielle Python-Docker-Image als Basis installieren, welches sich einfach in der Registry finden lässt. Der Container braucht keine besondere Konfiguration oder Ports. Nachdem wir das Python-Image heruntergeladen und den Container gestartet haben, verbinden wir uns in die Shell des Containers hinein:
sudo docker exec -i -t python1 /bin/sh

Nun installieren wir erst einmal Updates und vi via

apt-get update
apt-get upgrade
apt-get install vim

Anschließend ziehen wir uns das Git-Repo des Projektes runter:

git clone https://github.com/Findus23/rss2wallabag.git

Dieses Python-Projekt führt praktischerweise eine requirements.txt-Datei mit, die alle Pakete enthält, die man zur Ausführung des Scripts braucht, diese installieren wir nun:

cd rss2wallabag
pip install -r requirements.txt

Das Script wird über zwei Dateien konfiguriert, config.yaml und sites.yaml. Von beiden Dateien gibt es eine Beispieldatei, die wir uns nun kopieren und editieren.

cp config.example.yaml config.yaml
cp sites.example.yaml sites.yaml

Anschließend werden die Dateien mit vi bearbeitet. Die config.yaml wird mit Hostname, Client-ID, Client-Secret, Wallabag-Username und Passwort gefüttert. Für jedes externe Programm muss man in Wallabag eine Client-ID mit einem automatisch generieren Secret erzeugen; im Menu unter API clients management zu finden.
Den Github-Username kann man auskommentieren und Debug auf False belassen, möchte man bloß RSS-Feeds importieren. Achtung: Setzt man Debug auf True, werden keine Links zu Wallabag hinzugefügt, selbst wenn alles in Ordnung ist. Um das Script produktiv nutzen zu können, muss man dies deaktivieren, auch wenn die Shell-Nachrichten anderes behaupten.

In der sites.yaml gibt man den oder die Feeds an, die man parsen möchte, zusammen mit ihren Tags. Die erste Zeile, der Titel des Feeds, wird automatisch als Tag hinzugefügt. Das Feld latest_article muss ein <title> des Feeds sein — ab diesem Beitrag wird alles neue importiert. Diese Datei wird laufend aktualisiert, sodass hier stets der zuletzt hinzugefügte Beitrag zu sehen ist.

Das Script kann nun per python main.py laufen – die Ausgabe in der Shell zeigt an, was passiert ist. Genauso leicht lässt sich dies via DSM-Cron fernsteuern, einfach

docker exec -i python1 /bin/sh -c 'cd rss2wallabag && python main.py' als Cron mit root einrichten; den Container-Namen gegebenenfalls anpassen.

Das Script bietet leider keine Möglichkeit, Beiträge automatisch als gelesen zu markieren. Ich habe eine Quick-and-Dirty-Lösung gefunden, die allerdings nicht sehr elegant ist. Für meinen Anwendungsfall funktioniert sie aber, da ich alles, was per RSS zu Wallabag kommt, ohnehin als gelesen markieren will. Möchte jemand nur manche Feeds als gelesen markieren, sollte er sich diese Sache nochmals genauer anschauen und gegebenenfalls jemanden fragen, der von Python mehr Ahnung hat als ich.

Die Wallabag Python-API führt den Befehl post_entries aus, der hier im Detail zu sehen ist. Diese Funktion muss nun um das archive-Attribut mit dem Wert 1 ergänzt werden.
Wir müssen also das main.py-Script bearbeiten, in Zeile 117 findet sich, was wir suchen.

Diese Zeile sieht so aus:
await wall.post_entries(url=url, title=title, tags=tags), wir ändern sie wie folgt ab:

await wall.post_entries(url=url, title=title, tags=tags, starred=0, archive=1)

und speichern die Datei.
Beim nächsten Lauf wird das Script die Einträge nun als gelesen markieren.

Die folgenden Themen werden in der Wallabag-Artikelserie behandelt:
Einleitung —  Auf Vorrat gespeichert: Das eigene Web-Archiv auf dem NAS
Teil 1: Was kann Wallabag?
Teil 2: Wallabag via Docker auf Synology NAS
Teil 3: Wallabag-Tuning
Teil 4: Wallabag und Paywalls
Teil 5: Wallabag-Backup und Versionsupdates
Teil 6: RSS-Import zu Wallabag
Teil 7: Wallabag und eReader
Teil 8: Archivebox und Wallabag

Wie bei jeder Software und Datenbank empfiehlt es sich natürlich, regelmässige Backups der Daten anzufertigen. Bei Docker-Containern kann man dies prinzipiell auf zwei Arten machen: Erstens, indem man einen Order des Host-Systems in den Container einbindet — alle geschriebenen Daten landen also quasi direkt im Host-Dateibaum und können von da mittels rsync oder anderweitig weg gesichert werden.
Zweitens, indem man die entsprechenden Daten regelmäßig aus dem Container heraus und in sein Filesystem kopiert. Welchen Weg man wählt, ist prinzipiell egal – das Wichtige ist, daran zu denken, überhaupt Backups zu machen. Ich habe mich hier für die 2. Variante entschieden, da inbesondere der Asset-Ordner, der Artikelbilder zwischenspeichert, sehr kleinteilig ist und Hunderte oder Tausende Dateien enthalten kann. Die möchte ich nicht alle dauernd offen in meinem System herum liegen haben.

Bei Wallabag gibt es tollerweise eigentlich nur zwei Sachen, die man sichern muss: Erstens die SQLite-Datenbank und zweitens der eben erwähnte Asset-Ordner mit den Artikelbildern. Sieht das eigene Datenbank-Setup anders aus, muss man diesen Teil natürlich anpassen.
Zur Sicherung der Wallabag-Daten habe ich folgendes Bash-Script geschrieben:

# Datenbank aus dem Container kopieren
docker cp wallabag:/var/www/wallabag/data/db/wallabag.sqlite /volume1/dein/backup/order/auf/dem/nas/
# ... und die Datei auf aktuelles Datum umbenennen
mv /volume1/dein/backup/order/auf/dem/nas/wallabag.sqlite /volume1/dein/backup/order/auf/dem/nas/"$(date +"%Y-%m-%d")"-wallabag-db-backup.sqlite
# Dann den kompletten Asset-Ordner raus kopieren
docker cp wallabag:/var/www/wallabag/web/assets/images /volume1/dein/backup/order/auf/dem/nas/images
# Diesen Order der Handlichkeit wegen zippen
7z a -r -tzip /volume1/dein/backup/order/auf/dem/nas/wallabag-images.zip /volume1/dein/backup/order/auf/dem/nas/images
# Die Ordnerkopie löschen
rm -rf /volume1/docker/wallabag/images
# Und das ZIP ebenfalls entsprechend umbenennen
mv /volume1/docker/wallabag/wallabag-images.zip /volume1/dein/backup/order/auf/dem/nas/wallabag/"$(date +"%Y-%m-%d")"-wallabag-images.zip
# Danach den Cache leeren und den Container neu starten
sudo docker exec -i -t wallabag php /var/www/wallabag/bin/console cache:clear -e=prod
docker restart wallabag


Dieses Script habe ich als wallaback.sh gespeichert und lasse es per Synology-Cron einmal wöchentlich nachts laufen.
Die Frequenz kann man natürlich auf die eigenen Bedürfnisse anpassen.
Sollte der Container crashen oder das NAS-Setup den Bach heruntergehen, kann man somit die Daten sehr schnell wieder zurück spielen. Dieses Verhalten sollte man unbedingt dann, wenn alles funktioniert, testen, denn jedes Backup, das man nicht erfolgreich wiederherstellen kann, ist nutzlos. Hierzu bietet sich gleich folgendes Szenario eines Versionsupdates an, das man auch durchspielen kann, wenn gar kein solches ansteht¹:

Versionsupdates für Software, die in einem Docker-Container läuft, sind immer so eine Sache, aber glücklicherweise gestaltet sich die Wallabag-Aktualisierung einfach. Das hier beschriebene Vorgehen hat bei mir von Version 4.3.5 auf 4.3.7 einwandfrei und ohne Datenverlust funktioniert.

Zunächst fertigt man ein frisches Backup wie oben beschrieben an.
Danach stoppt man den Container. Wallabag ist nun erst einmal still gelegt. Dann läd man sich aus der Docker-Registry die neuste Version des Wallabag-Images, indem man nach Wallabag sucht und den latest Tag herunterlädt. Man sollte vorher die Versionsnummer im Docker-Hub überprüfen.

Ist das neue Image einsatzbereit, klickt man beim gestoppten Wallabag-Container auf „Action“ und „Clear“ und löscht somit alle Nutzdaten im Container. Anschließend wird der Container neu gestartet. Es wird die neueste Software-Version installiert, dies kann etwas dauern. Sieht man die gewohnte Login-Maske, hat alles geklappt und man kann sich dem Restore widmen.

Nun kopiert man die Datenbank wieder in den Container hinein:
docker cp /volume1/dein/backup/order/auf/dem/nas/wallabag/YYYY-MM-DD-wallabag-db-backup.sqlite wallabag:/var/www/wallabag/data/db/wallabag.sqlite

Die Assets muss man erst auf dem NAS entpacken und dann rein schieben, da im Container kein 7z zum Extrahieren bereit steht ². Dies tut man am besten in ein normalerweise nicht genutztes Verzeichnis (bspw das root-Homeverzeichnis), da ansonsten unter Umständen versteckte Synology-Ordner mit angelegt werden:

root@NAS:~# 7z x /volume1/dein/backup/order/auf/dem/nas/wallabag/YYYY-MM-DD-wallabag-images.zip

Diese kopiert man dann an Ort und Stelle zurück:
docker cp images wallabag:/var/www/wallabag/web/assets/

Anschließend nicht vergessen, den Ordner vom NAS zu löschen:
rm -rf images/

Zum Schluss leeren wir nochmals den Cache und starten den Container neu:

docker exec -i -t wallabag php /var/www/wallabag/bin/console cache:clear -e=prod
docker restart wallabag

Hat man die Datenbank und die Assets im eigenen Dateisystem liegen und die Ordner entsprechend eingebunden, kann man sich dies sparen und muss nach einem Versionsupdate nichts weiter tun. Das beschriebene Vorgehen gilt für Updates, die keine Datenbank-Migration beinhalten. Für diesen Fall gibt es auf der Hilfe-Seite eine Anleitung.

Achtung: Nach dem Versionsupdate schlugen alle Versuche, irgendwelche Artikel von heise.de hinzuzufügen, fehl (egal ob hinter der Paywall oder nicht) – Fehlermeldung Entry reloaded but content fetching failed. Nach stundenlanger Suche und Herumprobieren bin ich dann auf die Lösung gekommen: Die Zugangsdaten müssen im Site credentials management nochmals neu eingetragen werden. Warum, kann ich nicht sagen, jedenfalls funktioniert es dann wieder.

Die folgenden Themen werden in der Wallabag-Artikelserie behandelt:
Einleitung —  Auf Vorrat gespeichert: Das eigene Web-Archiv auf dem NAS
Teil 1: Was kann Wallabag?
Teil 2: Wallabag via Docker auf Synology NAS
Teil 3: Wallabag-Tuning
Teil 4: Wallabag und Paywalls
Teil 5: Wallabag-Backup und Versionsupdates
Teil 6: RSS-Import zu Wallabag
Teil 7: Wallabag und eReader
Teil 8: Archivebox und Wallabag

Wallabag destilliert Websites, indem es nur den Haupttext anzeigt und absichert – doch wie funktioniert das? Dahinter steckt das bekannte und robuste php-readability. Die Wallabag-Macher haben allerdings eine eigene Version namens graby gebaut. Dieses Tool errät quasi anhand des Verhältnisses von HTML und Plaintext, in welchem Bereich der HTML-Seite sich der Haupttext befindet und bereit diesen dann auf. Dies funktioniert natürlich nicht immer 100% perfekt, aber meist mindestens akzeptabel. In Wallabag gibt es einen Konfigurations-Ordner, der Profile für viele gängige Websites enthält. Diese enthält beispielsweise auch Informationen, wo der Author des Artikels im HTML gefunden werden kann oder weist den Parser an, eine „Druck“-Version statt der normalen Version herunterzuladen oder entstückelt mehrseitige Artikel. Sollte die Lieblings-Website hier nicht vorhanden sein, lässt sich auch schnell ein neues Profil anlegen.
All diese Dateien liegen in vendor/j0k3r/graby-site-config/domainname.tld.txt und lassen sich frei bearbeiten.

Wallabag ist sogar in der Lage, Paywalls zu umgehen und dahinter liegende Texte zu speichern — vorausgesetzt, man hat einen gültigen Login zum entsprechenden Web-Angebot. Die Software schaltet keinen Zugang frei ¹. Heise hat seit einiger Zeit ein Heise+ genanntes Premiumabo, bei dem alle Artikel aus allen Publikationen online und unter eindeutiger URL bereit stehen — ideal! Die erwähnten Seiten-Konfigurationen regeln auch die Paywall-Unterstützung, sodass wir die entsprechende Datei nun für heise.de bearbeiten müssen.

Wir machen uns also auf, die Heise-Paywall aufzusperren. Wir öffnen die Datei vi /var/www/wallabag/vendor/j0k3r/graby-site-config/heise.de.txt und fügen am Ende folgendes hinzu:

requires_login: yes
login_uri: https://www.heise.de/sso/login/login
login_username_field: username
login_password_field: password
not_logged_in_xpath: /html/body/div[1]/header/div[1]/div/section/a-login/a[1]
login_extra_fields: forward=
login_extra_fields: permanent=1
login_extra_fields: ajax=1


Was bedeuten diese Befehle?
requires_login schaltet die Paywall-Unterstützung für diese Website frei.
login_uri ist die URI der Seite, die die Formulardaten der Anmeldeseite entgegen nimmt, zu entnehmen der post-Variable des entsprechenden form der Seite, die die Felder für Nutzername und Passwort enthält.
login_username_field und login_password_field sind die Parameternamen des zu übermittelnden Usernamens und Passworts, also die HTML-Namen der entsprechenden Formularfelder der Eingabemaske.
not_logged_in_xpath dient für das System zur Unterscheidung, ob man eingeloggt ist, oder nicht. Mir ist nicht 100% klar, ob dieser Wert für Heise korrekt ist, ich habe in der Dokumantation nichts dazu gefunden. Schlimmstenfalls wird für jeden Heise-Request versucht, sich einzuloggen.
login_extra_fields hängt weitere Formularfelder an, die im Originalformular vorhanden sind und ich übernommen habe.

Für zeit.de / Z+ sieht die Konfiguration so aus:

strip_id_or_class: volume-teaser
requires_login: yes
login_uri: https://meine.zeit.de/anmelden
login_username_field: email
login_password_field: pass
not_logged_in_xpath: /html/body/div[3]/div[2]/header/div[2]/div[1]/a
login_extra_fields: permanent=on


zeit.de bietet nur ein begrenztes Kostenlos-Kontingent an, dieser Zähler wird aber nur in einem Cookie im Browser gespeichert und somit von Wallabag ignoriert.
strip_id_or_class: volume-teaser blendet den Dieser Artikel erschien in Zeit XX aus.

Möchte man für seine Lieblingsseite die Konfiguration herausfinden oder testen, ist es am Einfachsten, im Browser den Login-Vorgang einmal durchzuführen und mittels der Entwicklertools die entsprechenden Werte im Netzwerk-Tab einzusehen.

Die Zugangsdaten zur Website müssen nun noch in Wallabag unter Site Credentials eingetragen werden.
Ob die Paywall-Unterstützung funktioniert, lässt sich überprüfen, indem man eine Seite der entsprechenden Domain vorher zum Archiv hinzufügt und sie dann hinterher wieder neu abruft – die Länge des Inhalts und die Lesedauer müsste sich nun geändert haben.

Für Übermedien, dass Steady als Paywall nutzt, habe ich die Konfiguration nicht erfolgreich hinbekommen und kann die Artikel demnach leider nicht im Volltext lesen.

Schlägt das Inhalte-Parsing einer Website grundsätzlich fehl oder möchte man eine grundlegend neue Seiten-Konfiguration einpflegen, empfiehlt sich die Seite von FiveFilters, wo man visuell die CSS-Klassen herausfinden kann. Dies lässt sich dann herunterladen und als Datei importieren.

Die folgenden Themen werden in der Wallabag-Artikelserie behandelt:
Einleitung —  Auf Vorrat gespeichert: Das eigene Web-Archiv auf dem NAS
Teil 1: Was kann Wallabag?
Teil 2: Wallabag via Docker auf Synology NAS
Teil 3: Wallabag-Tuning
Teil 4: Wallabag und Paywalls
Teil 5: Wallabag-Backup und Versionsupdates
Teil 6: RSS-Import zu Wallabag
Teil 7: Wallabag und eReader
Teil 8: Archivebox und Wallabag

Wie die Grundlegende Konfiguration des Reverse Proxy im Synology NAS funktioniert, habe ich in einem anderen Text schon erläutert. Das Setup für Wallabag ist gleich: SSL via Letsencrypt mit HTTP/2, welches man via (Sub)domain auf einen internen Port des NAS umleitet.

Hat man seine (Sub)domain eingerichtet, kann man die Container-Umgebungsvariable SYMFONY__ENV_DOMAIN_NAME nun mit dem korrekten FQDN (dem kompletten Domain-Namen) anpassen. Dies passt dann die internen Wallabag-Links zu CSS und Grafiken entsprechend an. Nach einem Container-Neustart sollte Wallabag nun aus dem Internet unter der gewählten (Sub)domain erreichbar sein.

Dieses Setup funktioniert schnell und ohne viel Fummelei, allerdings ist die Konfiguration nicht wirklich optimal. Zum einen werden die Daten nicht komprimiert an die Clients gesendet, was gerade dann ein Problem sein kann, wenn der Upstream des eigenen Internet-Anschlusses nicht besonders schnell ist: Wallabag lädt dann zwar, aber schnarchlahm. Zum anderen wird kein „Cache-Control“-Header mitgesendet, der einem Browser signalisiert, gewisse unveränderliche Sachen wie CSS und JS-Dateien zu speichern, sodass diese bei einem erneuten Besuch nicht nochmals abgerufen werden müssen.

Beides kann man relativ leicht korrigieren, allerdings nur manuell in der nginx-Konfiguration und nicht in der Synology-GUI.
Schauen wir uns zunächst den Status Quo an. Hierfür bietet sich GTMetrix an, welches die fehlende GZIP-Komprimierung und den Cache bestätigt. GZIP kann man in der nginx-Konfiguration mittels eines kurzen Blocks hinzufügen.

Hierzu öffnet man diese mittels vi /etc/nginx/app.d/server.ReverseProxy.conf und sucht nach dem Wallabag-Domainnamen. Unter den Block mit ssl_certificate_key und add_header fügt man nun den unten gezeigten gzip-Block (i drücken, um in den Einfüge-Modus zu wechseln) ein. Der Beginn des server { sieht nun so aus:

server {
listen 443 ssl http2;
listen [::]:443 ssl http2;

server_name deinname.tld;

ssl_certificate /usr/syno/etc/certificate/ReverseProxy/xxx/fullchain.pem;

ssl_certificate_key /usr/syno/etc/certificate/ReverseProxy/xxx/privkey.pem;

add_header Strict-Transport-Security "max-age=15768000; includeSubdomains; preload" always;

gzip_min_length 1000;
gzip_buffers 4 8k;
gzip_http_version 1.0;
gzip_disable "msie6";
gzip_types text/plain text/css text/xml application/javascript text/javascript application/x-javascript application/xml;
gzip_vary on;
gzip on;
gzip_proxied any;

Diese Werte weisen nginx an, alles vom Typ Javascript, HTML, CSS, XML etc. on the fly zu komprimieren. Die Konfigurations-Datei speichert man nun ab (ESC, dann :wq!) und nach einem nginx-Neustart via sudo nginx -s reload sollte GTmetrix nun anzeigen, dass die gzip-Konfiguration funktioniert. Alternativ kann man dies auch in den Developer-Tools des Lieblings-Browsers sehen. Der msie6-Tag? Hey, gratuliere, wenn du dich an den noch erinnern kannst.

Das Browser-Caching (also die Anweisung an den Browser, sich nicht ändernde Inhalte für eine gewisse Zeit zu speichern) ist ein klein wenig komplizierter, weil man es für die beiden Speicherorte /wallassets/ und /assets/ getrennt angeben muss ¹.
Diesen Block fügt man nun unter den eben erstellten gzip-Block ein:

location /wallassets/ {
expires 30d;
add_header Pragma public;
add_header Cache-Control "public";
proxy_pass http://localhost:8887/wallassets/;
proxy_set_header Host $host;
proxy_buffering off;
}
location /assets/ {
expires 30d;
add_header Pragma public;
add_header Cache-Control "public";
proxy_pass http://localhost:8887/assets/;
proxy_set_header Host $host;
proxy_buffering off;
}

Alles, was nun in den beiden Ordnern /assets/ und /wallassets/ liegt, wird nun vom Browser für einen Monat zwischengespeichert. Ein enormer Gewinn bei den Ladezeiten! Der Port muss eventuell anpasst werden, ich verwende 8887.

Danach wieder mittels sudo nginx -s reload nginx neu starten und via GTMetrix checken. Hier sollte nun ein „A“-Note stehen — prima!
Das Problem an dieser Proxy-Config ist, dass das NAS sie bei jedem Neustart wieder überschreibt. Meine (zugegebenermaßen nicht besonders elegante) Lösung sieht so aus:
Nach erfolgreicher Änderung der Konfiguration kopiert man sich diese an einen sicheren Ort, hier bspw. /etc/nginx/:

cp /etc/nginx/app.d/server.ReverseProxy.conf /etc/nginx/server.ReverseProxy.maw

Diese geänderte Konfiguration schreibt man dann mittels eines kleinen Cron-Scripts bei jedem Neustart via Synology-Cron (als root) zurück:

cp /etc/nginx/server.ReverseProxy.maw /etc/nginx/app.d/server.ReverseProxy.conf
nginx -s reload

Achtung: Änderungen, die über die Synology-GUI am Reverse-Proxy-Script getätigt werden, werden hierdurch natürlich ignoriert, außerdem löschen Änderungen via GUI auch die manuelle GZIP-/Cache-Konfiguration, die man dann wieder nachholen muss. Damit solche Änderungen auch einfließen, muss man die Config wieder an einen anderen Ort kopieren und dann wieder zurück schreiben.

Die folgenden Themen werden in der Wallabag-Artikelserie behandelt:
Einleitung —  Auf Vorrat gespeichert: Das eigene Web-Archiv auf dem NAS
Teil 1: Was kann Wallabag?
Teil 2: Wallabag via Docker auf Synology NAS
Teil 3: Wallabag-Tuning
Teil 4: Wallabag und Paywalls
Teil 5: Wallabag-Backup und Versionsupdates
Teil 6: RSS-Import zu Wallabag
Teil 7: Wallabag und eReader
Teil 8: Archivebox und Wallabag

Wie schon in verschiedenen anderen Postings vorgestellt, bin ich ein Fan meines Synology-NAS und des darauf laufenden Dockers¹. Docker ermöglicht es, auf einfache Art und Weise Software zu installieren und dabei so zu abstrahieren, dass das normale „Wirts“-System abgeschottet wird und die Docker-Container nur das lesen / schreiben / können sollen, was man Ihnen explizit erlaubt. Mittels Docker kann man so Software installieren und ausprobieren, ohne sich das eigene System „zu versauen“. Dennoch sollte man vorsichtig sein und nicht blind jedes Image ziehen und in einem Container zum Laufen bringen: Der Docker-Hub ist mittlerweile ein Tummelplatz für Malware und es wurden auch schon Methoden gefunden, aus dem Container auszubrechen. Ganz besonders, wenn auch dem eigenen NAS alle persönlichen Daten liegen.

Das Wallabag-Interface

Das Image kann einfach durch die Suche gefunden werden und wird mittels Doppelklick heruntergeladen. Einmal fertig, kann aus dem Image ein Container erzeugt werden. Nach Konfiguration des Containers ist Wallabag dann sogleich auch unter dem gewählten Port unter der IP-Adresse des NAS verfügbar. Nach Anlegen eines Benutzeraccounts kann man nun Links hinzufügen und das System erst einmal auf Herz und Nieren testen, indem man die NAS-IP mit dem gewählten Port aufruft.

Für Firefox gibt es eine offizielle Erweiterung, ansonsten gibt es ein (auch unter iOS/Safari) funktionierenden Bookmarklet, das man sich aus der Konfiguration heraus installieren kann. Die Firefox-Erweiterung muss nach dem Download via about:addons konfiguriert werden und funktioniert dann gut. In ihr lassen sich auch Seiten direkt als gelesen markieren. Ein Wort der Warnung: Jede Website, die fortan mit Firefox angesurft wird, wird an Wallabag gesendet, um zu überprüfen, ob diese dort schon gespeichert wurde. Das kann man in den Wallaban-Logs sehen:
[10/Mar/2019:22:12:41 +0000] "GET /api/entries/exists.json?url=https://example.com/ HTTP/1.1" 401 105 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:66.0) Gecko/20100101 Firefox/66.0"

Dies ist sicherlich weniger kritisch, weil Wallabag ja auf dem eigenen Server läuft, kann aber auch ganz schön viel Lärm erzeugen. Dieses Verhalten kann man unter Indicate if page already saved ausschalten. Sollte das Feature eingeschaltet bleiben, unbedingt auf HTTPS für Wallabag achten.

Die Leseansicht von Wallabag

Den eigentlichen Datenimport habe ich wie folgt gelöst:

Erst einmal die Daten vom eigenen NAS in den Container übertragen (oder gleich den Order in den Container einbinden):
docker cp /volume1/docker/wallabag/import/pinboard_export_manual_fix.json wallabag:/var/www/wallabag/data/

Hier müssen natürlich der lokale NAS-Pfad und der Dateiname angepasst werden. Falls euer Container nicht wallabag heißt, müsst ihr auch das ändern.
Anschließend verbindet man sich in den Container ²:

sudo docker exec -i -t wallabag /bin/sh

Im Container angekommen, ist es keine schlechte Idee, das PHP-RAM-Limit hoch zu schrauben. Hier sollte man einen sinnvollen Wert wählen – mein NAS hat bspw. 8 GB RAM und 2GB davon darf PHP im Wallabag-Container nun im schlimmsten Fall verbrauchen.
Man startet vi und editiert die entsprechende DateiL

vi /etc/php7/php.ini

Nun muss man nach memory_limit suchen und die Zeile entsprechend verändern:

2048mb memory_limit.

Den Import der Lesezeichen kann man über die GUI erledigen, man sieht hierbei aber keinerlei Fortschritt und fliegt blind — ich empfehle daher den Import über die Kommandozeile, wo auch gleich geloggt wird, was los ist. Bei langem Import sieht man nur ein Webserver-Timeout und muss warten, bis der Import abgeschlossen ist.

Das Wallabag-Team hat in den Docs eine Übersicht von Kommandozeilen-Befehlen angefertigt.
All diese Befehle funktionieren nur korrekt, wenn man sich im Verzeichnis /var/www/wallabag/ befindet.

Also los, wir begeben uns an den Import:
cd /var/www/wallabag/

Und dann:

php bin/console wallabag:import --importer=pinboard --markAsRead=true martin /var/www/wallabag/data/pinboard_export_manual_fix.json -e=prod

Hier wird nun eine JSON-Datei im Pinboard-Format importiert. Hierbei muss mittels --importer= der korrekte Dienst / Importer gewählt werden, weil der Import sonst nicht funktioniert. --markAsRead=true bestimmt, ob die Einträge schon als gelesen markiert werden sollen und martin ist der Username des Accounts.

Während des Imports hagelt es dann Meldungen über Fehler, die aber meist nur auf Grund falschen Parsings von Zeitstempeln entstehen. Bleibt der Parser jedoch mit einem „Segmentation Fault“ stehen, muss man ihn neu starten und hat anschließend ein paar Duplikate in der Datenbank.

Der Output kann beispielsweise so aussehen:

/var/www/wallabag # php bin/console wallabag:import --importer=pinboard --markAsRead=true martin /var/www/wallabag/data/pinboard_export_manual_fix.json -e=prod
Start : 02-02-2019 7:29:45 ---
PHP Warning: DOMXPath::evaluate(): Invalid expression in /var/www/wallabag/vendor/j0k3r/graby/src/Extractor/ContentExtractor.php on line 1021
07:29:55 WARNING [app] Error while defining date ["e" => Exception { …},"url" => "http://example.com","date" => """ 11:16\n AM\n -\n 16\n Dec\n 2016 """] []

Nachdem alle alten Lesezeichen importiert wurden, sollte man Duplikate löschen, die durch teilweise Re-Importe vorkommen können:

php bin/console wallabag:clean-duplicates martin -e=prod
Der martin ist auch hier wieder der Username, den ihr ersetzen müsst.

Nun ist das eigene Archiv einsatzbereit und man kann testen, ob auch neue Links über das Bookmarklet oder das [+]-Zeichen hinzugefügt werden können.
Ich habe nach dem Import in den Einstellungen unter „Misc“ den lokalen Download von Grafiken eingeschaltet: Somit werden alle in Artikeln enthaltenen Grafiken lokal heruntergeladen und stehen dann auch noch zur Verfügung, wenn die Original-Grafiken schon gelöscht wurden.

Ebenfalls empfiehlt es sich, in den Einstellungen die nach dem eigenen Geschmack passenden Exportoptionen einzuschalten. Besonders praktisch ist der „Public Share“, welcher einen Text über einen öffentlichen Link zur Verfügung stellt. Allerdings sollte man hier aufpassen, keine Rechte Dritter zu verletzen. Es ist bspw. nicht in Ordnung, so einen Artikel, den man aus einer Paywall herausgehoben hat, öffentlich zu machen.

Die folgenden Themen werden in der Wallabag-Artikelserie behandelt:
Einleitung —  Auf Vorrat gespeichert: Das eigene Web-Archiv auf dem NAS
Teil 1: Was kann Wallabag?
Teil 2: Wallabag via Docker auf Synology NAS
Teil 3: Wallabag-Tuning
Teil 4: Wallabag und Paywalls
Teil 5: Wallabag-Backup und Versionsupdates
Teil 6: RSS-Import zu Wallabag
Teil 7: Wallabag und eReader
Teil 8: Archivebox und Wallabag