Netz - Rettung - Recht

Webserver sind ja nichts Besonderes, meinen eigenen Mailserver betreibe ich seit 2002, und einen “richtigen” Newsserver, der nicht nur ein paar lokale Gruppen führt, ebenfalls seit 2005 - und SSH samt SCP und Co. und ggf. FTP sind ja eh dabei. Was fehlt also noch in der Liste der “klassischen” Dienste? Richtig - derjenige, mit dem ich als letztes warm geworden bin und den ich am wenigsten nutze: IRC, der “Internet Relay Chat”.

Nach dem unerwarteten Tod eines Freundes an Ostern 2020 musste sich die Gemeinschaft der Szafe auch eine neue Lösung für die bislang mitgenutzten IRC-Server einfallen lassen, so dass in der Folge selbst ein Netzwerk aufgesetzt wurde - und da wollte ich auch gerne dabei sein und meinen eigenen Server aufsetzen und einbinden.

Ich fürchte, das hier wird ein eher technisch geprägter Special-Interest-Beitrag werden, aber sei es drum: es soll darum gehen, mit Hilfe des Newsservers INN Message-IDs für Usenet-Postings zu erzeugen, die neben ihrem primären Daseinszweck - ein Posting mit einer dauerhaft und global eindeutigen ID zu versehen - auch einen menschenlesbaren Inhalt haben.

Die große Zeit der Blogs als primäres, ja nahezu einziges Medium zum Teilen und Veröffentlichen der eigenen Gedanken ist seit Jahren vorüber; die sog. “Blogosphäre” vereinzelt. Das schließt nicht aus, dass es weiter große, vor allem kommerzielle bzw. kommerzialisierte Blogs mit tausenden Lesern und mehreren Beiträgen täglich gibt, aber der durchschnittliche Internetnutzer denkt vermutlich nicht an ein Blog, wenn er sich online äußern will. Diesen Blog haben vielmehr die sog. “Sozialen Medien” (social media), also bspw. Twitter, Facebook und Instagram, eingenommen. Und man vernetzt sich heutzutage auch eher dort als über Kommentare und Trackbacks in den eigenen Blogs.

Nicht nur Twitter mit seiner Beschränkung auf 280 Zeichen, auch Facebook ist per se aber wenig geeignet zur Veröffentlichung auch nur kürzerer, geschweige denn mittlerer oder gar langer Texte in der eigenen Timeline bzw. dem eigenen Profil; das beginnt schon mit dem Editor, der als Stil- und Gliederungselement nur Zeilenschaltungen (also Leerzeichen) kennt und nicht einmal einfachste Hervorhebungen (kursiv, fett) oder gar Überschriften ermöglicht. Diese technischen Unzulänglichkeiten sind aber gar nicht der entscheidende Punkt; auch ohne sie spräche vieles dafür, seine eigenen Inhalte auch selbst zu kontrollieren und nicht vom freien, weltweit verfügbaren und vernetzten World Wide Web einen großen Schritt zurück in die Welt der Onlinedienste der 90er Jahre zu machen, in der Inhalte nur innerhalb der jeweiligen Dienste (“Silos”) verfügbar sind. Und es mag zwar unwahrscheinlich sein, dass Facebook demnächst die Pforten schließt, aber die Welt dreht sich weiter und Internetkonzerne kommen und gehen … Deshalb hilft es auch nur bedingt, dass Facebook mit den wenig bekannten und genutzten Notizen (“Notes”) durchaus die Möglichkeit bietet, blog-artige Beiträge zu veröffentlichen, mit Überschriften, Aufzählungen, Hervorhebungen, Links und sogar einem Bild im Kopf der Seite.

Wenn man das Weblog-System Serendipity nicht nur nutzt, sondern auch testen möchte, empfiehlt es sich, neben dem “echten” eigenen Blog (der Live-Instanz) auch ein Testblog zu betreiben. Dort kann man dann jeweils den neuesten Code aus git auschecken und testen.

Um sicherzugehen, dass es sich auch wirklich um einen frischen Checkout handelt und nicht noch irgendwelche Dateien aus früheren Versionen “herumliegen”, lösche ich gerne die bisherige Installation und setze sie frisch auf. Dabei sollen aber die Datenbanken sowie vorhandene Plugins und Themes und Medien erhalten bleiben.

Für diesen Zweck verwende ich ein passendes Shellscript:

Webstatistik “macht” man heutzutage, so mein Eindruck, primär live und dann entweder mit Google Analytics, oder man legt - auch unter Datenschutzgesichtspunkten - lieber selbst Hand an und greift dann normalerweise zu Piwik. So war auch der Tenor der Antworten auf meine zwei Jahre zurückliegende Frage nach dem “Stand der Technik”.

Dieser Tage habe ich mich gefragt, ob sich nicht viele Fragen auch durch eine bloße Auswertung der Webserver-Logs beantworten lassen, und einmal geschaut, was mir das aus der Vergangenheit noch bekannte AWStats so macht. Und siehe da, die Software gibt es noch, und sie bekommt auch noch einmal jährlich ein Update, zumeist mit Daten zu neuen Browserversionen und Webcawlern.

Vor einigen Monaten hatte ich über letsencrypt, die neue Zertifizierungsstelle für TLS-Zertifikate, berichtet und demletzt meine guten Erfahrungen damit dargestellt. Doch HTTP ist ja nicht das einzige Protokoll, das einer Absicherung bedarf. Wie sieht es mit TLS-Zertifikaten für Mail (SMTP und POP3 oder IMAP) und News (NNTP) oder noch andere Dienste aus?

Grundsätzlich ist das kein Problem: vorhandene Zertifikate mit dem (oder den) passenden Hostnamen müssen nur eingebunden werden.

Die sozialen Netzwerke - Facebook, aber auch Twitter - besetzen zunehmend den Platz, den bisher andere, offenere Dienste eingenommen habe. Auf Twitter wird diskutiert; Facebook dient sowieso als allgemeine Informationsquelle, Veröffentlichungsplattform, Diskussions- und Kommunikationsmedium, zum Spielen pp. Das ist - glücklicherweise - nicht jedermanns Sache, aber unstrittig ist wohl, dass beide Netzwerke Reichweite haben und auch schaffen können.

Es ist also grundsätzlich keine schlechte Idee, Verweise auf aktuelle Beiträge, bspw. im eigenen Blog, auch dort zu veröffentlichen, was den RSS- oder Atom-Feed nicht ersetzt, ihn aber ergänzen kann. Tweets und Facebook-Posts kann man leicht und ohne Medienbruch an die eigenen Leser weitergeben (Retweet, Sharing), positiv hervorheben und - für die eigene Leserschaft - kommentieren. Ich vermute, dass manch einer RSS gar nicht mehr kennt oder nutzt und auch Blogs allein auf Facebook oder Twitter folgt. Kein Wunder also, dass aktuelle Blogsysteme über Plugins verfügen, die neue Beiträge auf Twitter und/oder Facebook veröffentlichen können (hat Serendipity eigentlich ein Plugin für Facebook?), und sonst hilft oft IFTTT (If this, then that) weiter.

In gleicher Weise kann man aber natürlich auch Hinweise auf andere Seiten aus dem eigenen Webangebot veröffentlichen bzw. - im Jargon der Sozialen Netzwerke - diese Seiten teilen, manuell oder automatisiert: ein neues Tutorial, die Ankündigung einer Tagung oder eines Vortrags, die Einladung zur Mitgliederversammlung oder zum Stammtisch, oder was auch immer von Interesse für andere auf dem jeweiligen Kanal sein könnte und nicht in einem Blogeintrag steckt. Wer das schon ausprobiert hat, wird sich vermutlich darüber gewundert haben, wie es anderen gelingt, diese Ankündigungen mit einem Teaser und einem passenden Bild zu versehen - oder etwas verstört irgendein kleines Icon von der betreffenden Seite plötzlich verzerrt in Übergröße als Vorschaubild wiedergesehen haben (gerne genommen: der stilisierte Briefumschlag, der eine Mailadresse kennzeichnet - oder gar ein Zählpixel). Woran liegt das, und wie macht man das richtig?

Der Schlüssel zur Antwort findet sich in einem Kommentar zu einem älteren Blogeintrag: das Open Graph protocol.

Vergangene Woche hatte ich darüber berichtet, wie man - unter Debian Jessie - PHP-FPM mit mod_fastcgi installieren kann. In den Kommentaren hatte Sven mir dann nachfolgend erläutert, wie sich die Einbindung einfacher und besser über mod_proxy_fcgi lösen lässt, vorausgesetzt, man hat (wie in Debian Jessie) einen Apache 2.4 vor sich.

Da mir das ebenfalls vorzugswürdig erscheint, beschreiben ich in der Folge nunmehr diese Variante.

Bereits vergangene Woche berichtete ich von meinen Irrungen und Wirrungen des letzten Jahrzehnts mit SSL/TLS im Web. Erst Ende 2015 hatte ich mich aufgerafft, über StartCom für einige Domains Zertifikate erstellen zu lassen, und parallel die Berichterstattung über Let’s Encrypt verfolgt.

Der Workflow für die Erstellung und Pflege von HTTPS-Zertifikaten kann schnell komplex werden:

• Am Anfang steht die Erzeugung eines Schlüsselpaares, denn das spätere Zertifikat wird nur derjenige verwenden können, der auch den passenden privaten Schlüssel hat.
• Dann ist für jedes Zertifikat ein Certificate Signing Request (CSR) zu erstellen; das ist quasi die Roh-Form des späteren Zertifikats mit den notwendigen Informationen, die darin enthalten sein sollen.
• Dieser CSR muss dann von der Zertifierungsstelle (Certificate Authority, CA) digital signiert werden.
• Das so entstandene Zertifikat muss gespeichert und in die Webserver-Konfiguration eingebunden werden.
• Der ganze Ablauf ist nur zielführend, wenn die CA von den verbreiteten Browsern anerkannt ist, den von ihr signierten Zertifikaten also vertraut wird. Dafür wollen die meisten CAs Geld. Zudem müssen sie sich über einen mehr oder weniger aufwendigen Weg zumindest vergewissern, dass derjenige, der ein Zertifikat für einen bestimmten Hostnamen ausgestellt haben möchte, über diesen auch verfügen kann.
• Zertifikate werden in der Regel nur für einen begrenzten Zeitraum - meistens ein Jahr - ausgestellt. Danach müssen sie (rechtzeitig!) verlängert werden.

Let’s Encrypt ist angetreten, diese Abläufe weitestmöglich zu vereinfachen.

Datenströme im Netz zu verschlüsseln ist wichtig, aber auch zunehmend Allgemeingut. Telnet würde sicherlich niemand mehr zum Zugriff auf einen entfernten Rechner nutzen; stattdessen nimmt man SSH. Auch bei anderen Protokollen ist die Übertragung von Passworten im Klartext schon lange out: es fing an mit APOP für den Zugriff über POP3 und CRAM-MD5 für SMTP-Auth, und schon etliche Jahre nutze ich nur noch POP3S/IMAPS/SMTPS, also eine komplette Verschlüsselung des gesamten Datenstroms. So hat auch das auf SSH basierende SCP/SFTP schon lange FTP ersetzt, und nachdem sich mittlerweile auch NNTPS und der verschlüsselte Zugriff auf IRC-Server verbreitet haben, bleiben nur noch wenige Protokolle “offen”.

Selbstverständlich sollte auch - zumindest - die Übertragung von Passworten via HTTP gesichert werden, was die Einrichtung von HTTPS erfordert. Je mehr sich webbasierte Dienste und Apps verbreiten, desto wichtiger ist das. Es ist allerdings - leider - nicht ganz so einfach.

Eigentlich wollte ich schon vor gut drei Jahren, im Januar 2013, über dieses Thema schreiben, als ich die ersten Backup-Jobs dieser Art eingerichtet habe, aber irgendwie ist aus dem angefangenen Entwurf nie ein fertiger Blogeintrag geworden. - Nun denn, auf ein neues.

Nicht nur der heimische Rechner will regelmäßig gesichert werden; auch bei dedizierten Servern oder vServern ist ein regelmäßiges Backup vonnöten, um im Falle eines Falles nicht ohne (Code und) Daten dazustehen. Früher war es üblich, dass zu einem Server auch ein - meist per FTP zugänglicher - Backupplatz gehörte, der genügend Raum für ein Backup (auch über mehrere Generationen) bot. Mittlerweile müssen solche Angebote aber nicht selten kostenpflichtig hinzugebucht werden oder stehen gar nicht mehr zur Verfügung. Zwar ist es natürlich möglich, die Datensicherung auf einen anderen (eigenen oder fremden) Server durchzuführen, wobei sich die Maschine im heimischen Keller in der Regel wegen der geringen Upload-Bandbreiten nicht anbietet - schließlich will man nicht nur sichern, sondern notfalls auch wiederherstellen können. Eine Alternative ist aber Cloud-Speicher, bspw. Amazons S3 (Simple Storage Service). Die Kosten sind bei inkrementiellen Backups überschaubar: ein Gigabyte Speicherplatz kostet pro Monat ungefähr 3 Cent, dazu kommen noch geringen Kosten für Zugriffsoperationen in der Größenordnung von einem halben Cent pro 1.000 Zugriffe und für den ausgehenden Traffic - also vor allem für einen Restore - 9 Cent pro GB, jeweils zzgl. MWSt. Wöchentliche inkrementielle Backups mit monatlichen Vollbackups für vier Server kommen auf gut 10$.

Nicht selten lassen sich die meisten Seiten einer Webpräsenz aus demselben Template erzeugen, wohingegen einige Ausnahmefälle einer Sonderbehandlung bedürfen - bspw. die Startseite oder landing page, die oft anders gestaltet ist als der Rest der Webseiten, und sei es nur, dass sie keine oder andere Navigations-Elemente aufweist oder mehrspaltig statt einspaltig (oder umgekehrt) dargestellt werden soll.

Mag es bei der Verwendung von nanoc für eine singuläre Ausnahme noch sinnvoll sein, sie explizit in die - bereits erläuterte - Rules-Datei aufzunehmen, gibt es für diese Aufgabenstellung eine sehr einfache Lösung: ein abweichendes Template kann nämlich im YAML-Metadatenblock jeder Seite angegeben werden.

Sollen nun die Webseiten einer Präsenz normalerweise das Template namens default verwenden, die Startseite aber das Template startpage, so erhält die Quellcode-Datei der Startseite einen entsprechenden Eintrag in ihre YAML-Metadaten, bspw. template: startpage, und die Rules-Datei erhält dann im compile-Block an der passenden Stelle - statt layout 'default' - die Anweisung layout item[:template] || 'default'.

Man kann auch - wie es der CCCS tut - die Variante “gar kein Template” direkt mit aufnehmen:

if item[:template]!='none'
  layout item[:template] || 'default'
end

Bei der Gestaltung einer Website sollten Links gut als eben solche erkennbar sein - am besten unterstrichen und in dem gewohnten blauen Farbton, damit der Nutzer sie im Fließtext erkennen kann (in der Navigation ist das nicht von vergleichbarer Wichtigkeit, weil dort mit “klickbaren” Texten gerechnet wird).

Bestimmte Arten von Links möchte man oft dennoch abweichend kennzeichnen - zum Beispiel “mailto:“-Links, also solche, die nicht auf eine andere Webressource, sondern auf eine E-Mail-Adresse zeigen, und vielleicht auch andere Links, deren URL ein ungewohntes Protokoll enthält.

Kennzeichnung von Links mit Grafiken

Man könnte solche Links in verschiedenen Farben anzeigen, aber das wäre alles andere als selbsterklärend, und der Websurfer heutiger Tage dürfte wohl kaum erst eine Erläuterungseite zur Gestaltung der betrachteten Webpräsenz studieren wollen, um sich zu vergewissern, was ihm ungewohnte Farben und Symbole sagen wollen. Unmissverständlich hingegen ist ein Icon, für eine E-Mail-Adresse bspw. ein Briefumschlag (früher auch gerne ein - am besten blinkendes oder rotierendes - @-Symbol). Auf diese Weise kann man Links auf E-Mail-Adressen zum Beispiel so auszeichnen:

<img src="/imgs/envelope.gif" /> <a href="mailto:thh@inter.net">thh@inter.net</a>

Für den Fall, dass häufiger Mailadressen im Text vorkommen, ist das allerdings etwas aufwendig, vor allem, wenn man das Prinzip auch noch auf andere Arten von Links ausdehnen möchte. Werden die Webseiten ohnehin durch eine Skriptsprache generiert, bspw. durch PHP, kann man stattdessen natürlich eine passende Funktion verwenden, die bspw. über den Aufruf mailto('thh@inter.net') die obige Ausgabe erzeigt. So richtig elegant ist das aber immer noch nicht.

In anderen Blogs fand ich es immer ganz schön, wenn Kommentare des ursprünglichen Autors - des Blogeintrags - optisch hervorgehoben werden. Wer das gleichfalls schick findet, kann das auch mit Serendipity umsetzen.

Voraussetzung ist, dass im verwendeten Theme (oder Template) zum einen entsprechender Smarty-Code vorhanden ist, der auf die Übereinstimmung von “Kommentarautor” und “Blogautor” prüft, und es zum anderen dort entsprechende CSS-Definitionen gibt, die dann zu einer Hervorhebung führen. Ersteres ist im neuen Standardtheme “2k11” der Fall, letzteres nicht.

Wenn die Überprüfung ergibt, dass der Kommentar vom Autor des Beitrags selbst stammt, bekommt der entsprechende <article>-Abschnitt die Klasse serendipity_comment_author_self zugewiesen. Für diese Klasse sind also entsprechende Definitionen vorzunehmen, die dann zu einer optischen Hervorhebung führen. Dazu erstellt - oder ergänzt - man eine entsprechende Datei namens user.css im Verzeichnis des Themes (templates/2k11) entsprechend (deren Nutzung freilich in der Konfiguration des Themes aktiviert sein muss), bspw. so wie hier in diesem Blog:

Die Überprüfung erfolgt standardmäßig auf Identität der jeweils angegebenen Namen von Kommentar- und Eintragsautor, nicht über die Identität der E-Mail-Adresse. Das lässt sich natürlich ändern, bspw. in der Datei comments_by_author.tpl im Theme-Verzeichnis (templates/2k11). Bei einer Überprüfung auf Identität der E-Mail-Adresse wäre aber zu prüfen, ob nicht etwa ein Spamschutz-Plugin die Ausgabe der E-Mail-Adressen unterdrückt; falls doch, stehen die entsprechenden Daten für Smarty nicht zur Verfügung. Nachdem zumindest in 2k11 ohnehin über das Template selbst die Ausgabe der Mailadressen unterbunden wird, kann man die entsprechende Spamschutz-Konfiguration aber auch getrost deaktivieren.

Im Serendipity-Forum finden sich zu den näheren Einzelheiten u.a. folgende Threads:

• 2k11 und Kommentare vom Autor
• Way to indicate comments made by (logged in) user/admin

Beachten sollte man im übrigen, dass natürlich letztlich jedermann Namen und E-Mail-Adresse des Blogautors für Kommentare verwenden kann …

DokuWiki ist für mich derzeit und schon länger die generische Antwort auf die Frage nach einem Wiki, nicht nur für Dokumentationszwecke, und auch für die Frage nach einem (simplen) CMS.

Ich installiere DokuWiki dabei (wie die meisten Webapplikationen) nicht als Debian-Paket, sondern direkt vom Erzeuger; zum einen, weil ich gerne eine aktuelle Version habe, zum anderen, weil ich dann (wie bei anderen Webseiten) frei entscheiden kann, wo die Dateien liegen sollen - und das ist in der Regel nicht dort, wo Debian sie ablegen würde, insbesondere, wenn es mehr als einen Nutzer mit Webseiten geben soll - und nicht zuletzt, weil das trivial funktioniert. Das führt dazu, dass ich Updates von Hand durchführen muss, und das kann dann schon etwas nervig werden, wenn es mehrere Hosts und mehrere Wikis betrifft.

Daher überlege ich schon länger, wie ich - zumindest bei Installationen auf demselben Host - den Aufwand (und, natürlich, auch den Platzverbrauch) minimieren kann. Die offenkundige Lösung ist eine “Farm”- oder “Multisite”-Installation, bei der der Code nur einmal vorhanden ist, aber jedes Wiki seine eigenen Konfiguration und natürlich seinen eigenen Speicherplatz für Inhalte hat. DokuWiki unterstützt das prinzipiell, aber die nächste Frage ist ja immer, wie gut das auch tatsächlich funktioniert: stabil, flexibel und vor allem ohne krude Hacks.

Nachdem ich mich diese Woche damit beschäftigt habe, kann ich sagen: es funktioniert gut. Die Flexibilität bleibt erhalten, Hacks braucht man nicht, weil die aktuellen DokuWiki-Versionen eine “Multisite”-Installation unterstützen, und stabil wirkt es bisher auch.

Der offensichtliche Vorteil liegt darin, dass man für beliebig viele Wikis nur einmal den Code für das Wiki selbst - und den für Plugins und Templates - installieren, updaten und pflegen muss. Der offensichtliche Nachteil liegt darin, dass alle Plugins und Templates im “Master”-Wiki installiert werden müssen und in den einzelnen Wikis nicht nachinstalliert werden können, und dass sich alle Wikis in Unterverzeichnissen unter einem “Stammverzeichnis” befinden müssen, deren Namen identisch mit der URL des Wikis sind.