Netz - Rettung - Recht (Artikel mit Tag anleitung)

irc.szaf.org

nospam@example.com (Thomas Hochstein) — Thu, 11 Feb 2021 06:20:00 +0000

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.

Installation und Erstkonfiguration

Ich befürchtete schon, das werde sicherlich ganz furchtbar kompliziert, aber dem war angenehmerweise nicht so. Die Software-Wahl war auf den ngircd gefallen, den “next-generation IRC daemon”, und der ist in Debian verfügbar: apt install ngircd reicht also aus, und dann muss nur noch ein wenig an der Konfiguration in /etc/ngircd/ngircd.conf geschraubt werden:

    Name = irc.szaf.org

    AdminInfo1 = (Info zum Administrator, Zeile 1)
    AdminInfo2 = (Info zum Administrator, Zeile 2)
    AdminEMail = (Mailadresse des Administrators)

    Info = Szeep on IRC
    ;MotdPhrase = "irc.szaf.org SzafNet IRC Server. Ready. Bleat ahead."

    Network = szafnet

    Password = Swordfish

[Limits]
    MaxJoins = 20
    MaxNickLength = 25

Wenn man will, kann man auch noch die Zugangsdaten für einen IRC-Operator hinterlegen:

[Operator]
    Name = thh
    Password = pass123

TLS

Dazu dann noch eine Webseite, über die es ein Zertifikat von Let’s encrypt gibt, das man dann auch dem IRC-Server verfüttern kann; die grundsätzliche Vorgehensweise hatte ich ja bereits vor knapp fünf Jahren beschrieben.

Erstmal das Zertifikat einkopieren …

mkdir /etc/ngircd/certs/
cp /etc/letsencrypt/live/irc.szaf.org/fullchain.pem /etc/ngircd/certs/
cp /etc/letsencrypt/live/irc.szaf.org/privkey.pem /etc/ngircd/certs/

… und in der Konfiguration (/etc/ngircd/ngircd.conf) einrichten:

[SSL]
    # SSL-related configuration options.
    CertFile = /etc/ngircd/certs/fullchain.pem
    KeyFile = /etc/ngircd/certs/privkey.pem
    Ports = 6697

Nach service ngircd restart sind wir dann im Geschäft.

Das ganze lässt sich auch automatisieren - ich baue mir ein kurzes Shellscript, bspw. /etc/ngircd/certbot-deploy-certs.sh:

#!/bin/dash
cp /etc/letsencrypt/live/irc.szaf.org/fullchain.pem /etc/ngircd/certs/
cp /etc/letsencrypt/live/irc.szaf.org/privkey.pem /etc/ngircd/certs/
/usr/sbin/service ngircd reload

und mache es ausführbar (chmod 755 /etc/ngircd/certbot-deploy-certs.sh) und setze einen entsprechenden Cronjob vor denjenigen, der alle abgelaufenen Zertifikate rundum erneuert.

Ein kleines Manko hat die ganze Sache noch: leider kann erst der ngIRCd 26~rc1 ein TLS-Zertifikat im laufenden Betrieb nachladen, wenn er mit GnuTLS arbeitet, wie das bei Debian der Fall ist; in früheren Versionen geht das nur bei OpsenSSL. Leider hat Debian Stretch nur die Version 24-1, und auch das aktuelle Debian Buster nur die Version 25-2. Das Script funktioniert also bisher nicht; zwar wird das neue Zertifikat einkopiert, aber der Server verarbeitet es nicht. Dafür wäre ein service ngircd restart notwendig - der aber die Verbindung zu allen Clients und allen verbundenen Servern trennt. Bislang habe ich daher einen alle drei Monate wiederholten Eintrag in meinem Todo-System, um nach dem Zertifikat zu schauen und ggf. den Server manuell zu starten. Mit dem künftigen Debian Bullseye sollte das dann ein Ende haben.

Vernetzung mit anderen IRC-Servern

Alleine chatten ist nett, ein IRC-Netzwerk aufzubauen noch netter. Zu diesem Zweck muss man dem ngircd nur verklicken, welche anderen Server “dazugehören”, und mit denen ein Passwort vereinbaren. Jeder Serverbetreiber notiert dann das eigene Passwort und das der Gegenstelle in der Konfiguration, und schon vernetzen sich die Server - jeder allerdings immer nur mit einem anderen, die Topologie bildet also Linien, keine Sterne. Wenn aber ein Server aus dem Netz fällt, bspw. weil er restartet wird, verbinden sich die verbleibenden Server neu, bis sie alle wieder miteinander verbunden sind.

Eine solche Konfiguration kann dann bspw. so aussehen:

[Server]
    Name = irc.anderer-server.example
    Host = irc.anderer-server.example
    Port = 6697
    MyPassword = OhmyOhmyOhmy
    PeerPassword = Ramalamadingdong
    Group = 1
    Passive = no
    SSLConnect = yes

Das weist diesen Server der Gruppe 1 zu (wenn ein Server innerhalb einer Gruppe nicht verfügbar ist, wird ein anderer ausprobiert), lässt automatische Verbindungen zu und verlangt dafür SSL/TLS. Die Gegenstelle (irc.anderer-server.example) muss natürlich die Werte für MyPassword und PeerPassword vertauschen.

Server neu starten, et voilà: das IRC-Netzwerk steht. Das war einfach - und tut seit April 2020 sehr zuverlässig.

Titelbild © AliFuat - stock.adobe.com

[Nachträglich veröffentlicht im August 2021.]

"Sprechende" Message-IDs erzeugen mit dem INN

nospam@example.com (Thomas Hochstein) — Wed, 15 Apr 2020 06:00:00 +0000

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.

Message-IDs, ihr Aufbau und ihre Funktion

Der Message-ID-Header verleiht jedem Beitrag im Usenet (jedem Posting) und jeder E-Mail eine absolut eindeutige, nur einmal vergebene Kennung, mit der das Posting oder die E-Mail referenziert werden können.

Funktion

Die Notwendigkeit dafür ist einmal technischer Art; so können Postings und E-Mails bspw. in Logdateien eindeutig bezeichnet werden. Auch ist die Message-ID für das Threading - also die Darstellung von Postings oder E-Mails in einem “Diskussionsfaden” erforderlich; denn dazu enthält jede E-Mail die Message-ID ihres Vorgängers, also die Kennung der Nachricht, auf die sie die Antwort enthält. Bei Postings ist das ähnlich; nur werden dort die Message-IDs aller (oder bei langen Threads zumindest etlicher) Vorgänger übermittelt. So können Newsreader und Mailprogramme Bezugsverkettungen aufbauen und E-Mails (oder Postings) im Zusammenhang darstellen, ohne sich dabei auf Zufälle wie einen identischen Betreff verlassen zu müssen.

Im Usenet hat die Message-ID noch eine weitere wichtige Bedeutung: Postings werden im Gegensatz zu E-Mails nicht nur an einen oder mehrere bestimmte Empfänger übermittelt, sondern im “Floodfill”-Verfahren an alle miteinander vernetzten Newsserver verteilt. Diese Newsserver sind aber regelmäßig nicht nur einfach, sondern vielfach miteinander vernetzt und erhalten daher jeden Beitrag mehr- oder vielfach auf verschiedenen Wegen. Um Übertragungskapazität zu sparen (und Duplikate zu vermeiden) lehnen sie daher die Annahme von Beiträgen, die sie schon kennen, ab und speichern diese auch nicht, falls sie doch übertragen werden. Daraus folgt, dass ein Posting, dass eine bereits einmal verwendete Message-ID enthält, nicht verteilt wird; und schlimmer noch, dass eine Änderung der Message-ID zur mehrfachen Verteilung und Speicherung von Postings, also zu unerwünschten Duplikaten führt. Deshalb sollte man an der Message-ID von Postings, die nicht lokal erzeugt wurden, auch niemals herumfummeln und generell genau wissen, was man tut, wenn man die Message-ID manipuliert.

Unabhängig von diesen technischen Aufgaben ist die Message-ID auch der geeignetste Weg, im Usenet auf einen bestimmten anderen Beitrag zu verweisen. “Schau mal in das Posting von Hans Meier von gestern, 17.32 Uhr, da steht die Antwort auf Deine Frage” ist so aufwendig - für Schreiber und Leser - wie unprofessionell. “Schau Dir mal <d648ee74-9def-e5ca-8c12-9a347fce0dc5@host.example> an, da steht alles drin” ist hingegen schnell geschrieben (es genügt ein Kopieren der Message-ID) und ebenso schnell aufrufbar, weil Newsreader in der Regel den Aufruf von Postings anhand der Message-ID ermöglichen.

Aufbau einer Messsage-ID

Vom Aufbau her ähnelt eine Message-ID sehr einer E-Mail-Adresse: sie hat einen linken und einen rechten Teil, die durch ein @-Symbol miteinander verknüpft sind und wird von spitzen Klammern (<>) eingerahmt. Weil das sehr dem Konzept einer lokalen Adresse und einer Domain ähnelt, wird die Anforderung, dass Message-IDs global eindeutig sein müssen, am besten so umgesetzt, dass das die ID erzeugende System auf der rechten Seite seinen (weltweit eindeutigen) Hostnamen einsetzt und auf der linken Seite eine Zeichenfolge verwendet, die systemweit eindeutig ist, in der Regel also aus einem Timestamp, ggf. einer Prozess-ID oder einem Zähler besteht. Das Format wäre also <unique@hostname>.

Das funktioniert prima, solange das System einen (eindeutigen) Hostnamen hat; für den typischen (Windows-)Heimrechner ist das allerdings nicht der Fall. Dann kann man die Erzeugung der ID entweder dem Newsserver überlassen, der ja in der Regel im Netz erreichbar sein muss und daher über eine IP-Adresse und einen auch als FQDN bezeichneten domainisierten Hostnamen (news1.provider.example) verfügt. Alternativ kann man dem Newsreader einen Hostnamen (FQDN) vorgeben; das muss nicht zwingend der tatsächliche Hostname des Rechners sein, es genügt auch ein Name, der garantiert nicht anderweitig vergeben werden kann, wie ihn bspw. das Projekt My FQDN zur Verfügung stellt. Schließlich kann man, wenn alle Stricke reißen und man die Message-ID unbedingt selbst generieren will, auf die Mailadresse des Autors abstellen, für die Adresse localpart@domain dann etwa so: <unique.localpart@domain>.

Beispiele für Message-IDs

In der Praxis sieht bspw. eine durch den Newsserver INN erzeugte Message-ID so aus:

<r6d9hs$4cu$1@thangorodrim.ancalagon.de>

Auf der rechten Seite steht der Hostname des Newsservers (hier thangorodrim.ancalagon.de), auf der linken Seite finden sich (nacheinander und getrennt durch $) ein Timestamp (hier r6d9hs), die Prozess-ID des Serverprozeses (hier 4cu) und - für den Fall, dass in derselben Sekunde vom selben Prozess mehrere Beiträge entgegengenommen werden - ein Zähler (hier 1). Timestamp und Prozess-ID werden dabei in einem Zahlensystem auf der Basis 32 kodiert; dezimal lautet der Timestamp also 912696892 und die Prozess-ID 4510. Und tatsächlich: wie das Logfile des Newsservers zeigt, wurde der Beitrag von dem Prozess Nummer 4510 angenommen:

thangorodrim nnrpd[4510]: thangorodrim.ancalagon.de (127.0.0.1) connect - port 119

Beim Timestamp muss man nun noch wissen, dass der INN vom tatsächlichen Unix-Timestamp (also der Anzahl der Sekunden seit der Epoche, d.h. seit 01.01.1970 00:00:00) wahllos 673416000 abzieht, um eine kürzere Message-ID zu erhalten. Zählt man also zu dem Timestamp von 912696892 noch 673416000 hinzu, erhält man 1586112892 - und das ist umgerechnet der 05.04.2020, 18:54:52 Uhr: passt!

Der Newsreader slrn arbeitet ähnlich:

<slrn94p19c.ns.thomas@thangorodrim.ancalagon.de>

Die Message-ID besteht aus dem Namen des Newsreaders (slrn), einem verkürzten Zeitstempel im 32er-Zahlensystem (94p19c), der Prozess-ID (ns) und der Mailadresse des Nutzers (bzw. seinem Usernamen und dem Hostnamen).

Vorteile einer selbst erzeugten Message-ID

Am einfachsten wäre es natürlich, die Erzeugung von Message-IDs dem Newsserver zu überlassen; andererseits hat die Erzeugung eigener Message-IDs durchaus Vorteile. Manche Newsreader benötigen das schon deshalb, weil sie eigene Postings auch ablegen und speichern wollen. Ganz allgemein hat eine selbst erzeugte Message-ID aber den Vorteil, dass man (nur) an ihr sehr einfach eigene Beiträge erkennen kann, auch dann, wenn man vielleicht wechselnde E-Mail-Adressen verwendet, und dass man nur so auch Antworten auf eigene Beiträge erkennt (weil diese eine Message-ID mit dem eigenen FQDN im References-Header tragen). So kann ein geeigneter Newsreader bspw. Antworten auf eigene Postings hervorheben, oder man kann sich mit einem Tool wie fupcheck per Mail über Antworten benachrichtigen lassen.

“Sprechende” Message-IDs

Noch schöner finde ich es persönlich, wenn die Message-ID meiner Postings nicht nur global eindeutig ist, sondern auch für den menschlichen Leser verwertbare Informationen enthält. So ist es ja theoretisch nett, dass ich aus der Message-ID <r6d9hs$4cu$1@thangorodrim.ancalagon.de> herauslesen kann, dass es sich um ein Posting vom Abend des 05.04.2020 handelt - aber natürlich wird kaum je ein Mensch r6d9hs in eine Dezimalzahl umwandeln, 673416000 hinzuzählen und das Ergebnis dann von einem UNIX-Timestamp in ein Datum konvertieren. Viel praktischer wäre es doch, wenn man einer Message-ID direkt ansehen könnte, von wann sie ist, und am besten vielleicht auch von wo, d.h. aus welcher Newsgroup. Dann muss man sich nicht wundern, wenn mal wieder jemand erst nach Monaten oder Jahren auf einen alten Beitrag antwortet, und man kann auch an einer zitierten Message-ID ungefähr ablesen, wo sie herkommt.

Ich erzeuge daher seit vielen, vielen Jahren unter Hinzunahme meines Hamsters “sprechende” Message-IDs, die aus den Initialen der (ersten) Newsgroup, in der der Beitrag erschienen ist, einem lesbaren Zeitstempel und einem Zähler bestehen. Der Beitrag mit der Message-ID

<dcsn.1908202159.235@meneldor.ancalagon.de>

ist mithin am 20.08.2019 um 21.59 Uhr von meinem Laptop meneldor aus in der Newsgroup d.c.s.n erschienen; letzteres kann man mit etwas Erfahrung als de.comm.software.newsreader (oder auch de.comm.software.newsserver - natürlich sind Initialen nicht eindeutig!) übersetzen. Außerdem handelte es sich um den 235. Beitrag im Jahr 2019; das ermöglicht mir zudem durch einen schlichten Blick in die Datei, in der der Zähler gespeichert wird, die Gesamtzahl meiner Beiträge im jeweiligen Jahr zu erfassen.

Klar, das ist eine Spielerei, aber eine für mich hilfreiche - und liebgewonnene - Spielerei.

“Sprechende” Message-IDs mit dem INN erzeugen

Nun habe ich in letzter Zeit öfters mal von verschiedenen Rechnern aus mit verschiedenen Newsreadern (nicht nur zu Testzwecken) auf meinem “hauseigenen” INN gepostet. Und da hätte ich dann gerne - auch ohne Hamster - meine sprechenden Message-IDs, die der INN für mich setzen müsste.

Der richtige Ansatzpunkt für solche Manipulationen ist der Filter filter_nnrpd.pl (bei Debian in /etc/news/filter/), der nur auf dem Server über den NNRP-Daemon (nnrpd) gepostete Beiträge bearbeitet, nicht aber etwa ein- und durchgeleitete Beiträge wie der filter_innd.pl - denn an Message-IDs schon geposteter Beiträge herumzufummeln ist ein absolutes No-Go!

Insbesondere wenn man den Server nicht alleine nutzt, möchte man die Veränderungen an der Message-ID auf eigene Postings beschränken; das kann man zum Beispiel durch einen Filter auf den Domain-Part (also die rechte Seite der Message-ID) lösen oder indem man nur Postings bearbeitet, die einen entsprechenden Zusatzheader (wie bspw. X-Fix-MID: yes) gesetzt haben.

Im filter_nnrpd.pl gibt es die Funktion filter_post; dort sind wir richtig. Am Anfang sollte man auf jeden Fall den Rückgabewert der Funktion auf einen leeren String setzen, denn ansonsten werden Postings mit einer Fehlermeldung abgewiesen. Außerdem muss man das Verändern von Headern freischalten:

my $rval = ""; # assume we'll accept.
$modify_headers = 1;
# [...]
return $rval;

So weit, so gut. An der mit “[…]” markierten Stelle prüfen wir jetzt, ob das Posting modifiziert werden soll oder nicht; wenn ja, rufen wir eine - noch zu schreibende - Funktion dafür auf:

# Fix Message-ID
if (exists($hdr{'X-Fix-MID'})) {
    # remove trigger header
    delete $hdr{'X-Fix-MID'};
    # fix MID
    $hdr{'Message-ID'} = fix_mid($hdr{'Newsgroups'}, $hdr{'Message-ID'});
}

Ist die Headerzeile X-Fix-MID auf irgendeinen Wert gesetzt, entfernen wir sie und setzen dann die Message-ID auf den Rückgabewert der Funktion fix_mid. Und die sieht wie folgt aus:

#
# Message-ID
#
sub fix_mid($$) {
    my ($newsgroups, $mid) = @_;
    my ($fqdn, $element, $initial)= '';
    # get FQDN
    if (defined($mid) && $mid ne '') {
       ($fqdn) = $mid =~ /<.+\@(.+)>$/;
    } else {
       $fqdn = $inn::fromhost;
    }
    # get timestamp
    my $datetime = strftime("%Y%m%d%H%M%S",localtime());
    # get initials of first newsgroup
    my($newsgroup,undef) = split /,/, $newsgroups;
    my @newsgroup = split /\./, $newsgroup;
    foreach $element (@newsgroup) {
       $initial .= substr($element,0,1);
    };
    # get, increment and save counter
    open CTR, '+</var/lib/news/mid-counter';
    flock(CTR, 2);
    my $counter = <CTR>;
    $counter++;
    seek(CTR,0,0);
    print CTR $counter;
    close CTR;
    # return Message-ID
    return sprintf('<%s.%s.%s@%s>', $initial, $datetime, $counter, $fqdn);
}

Wir übernehmen also den Domain-Part der bestehenden Message-ID; nur wenn es bisher keine Message-ID gibt, nehmen wir den Hostnamen des Newsservers. Dann generieren wir den Zeitstempel, die Initialen der (ersten) Newsgroup und laden und schreiben den Zähler; letzteres ist natürlich mit Plattenzugriffen verbunden. Am Schluss werden die Einzelteile zu einer Message-ID zusammengesetzt.

Voila!

Nachtrag vom 10.01.2021: Die meisten Newsreader nutzen natürlich mehrere parallele Threads zum Lesen und Posten. Das geht dann schief, wenn deshalb verschiedene nnrpd-Prozesse gleichzeitig auf die Datei /var/lib/news/mid-counter zugreifen. Daher bedarf es eines exklusiven Locks auf die Datei, schon beim Lesen, damit nicht mehrere Prozesse denselben Zahlenwert erhalten; und weil beim Schließen eines Dateihandles auch die Locks aufgegeben werden, muss die Datei zum Lesen und Schreiben geöffnet werden. Und wenn man das wiederum tut, muss man nach dem Lesen zurück an den Anfang der Datei springen, um den alten Inhalt mit der neuen Zahl zu überschreiben. Den Beispielcode oben habe ich entsprechend angepasst.

(Und wenn man das testen will, sollte man bedenken, dass filter_nnrpd.pl immer dann, aber auch nur dann neu geladen wird, wenn ein neuer nnrpd-Prozess startet - dementsprechend also nicht, wenn der Newsreader die Verbindung erst einmal offen hält und weitere Testposts dann über die noch bestehende Verbindung abgesetzt werden.)

Titelbild © Weissblick - stock.adobe.com

Blogbeiträge in sozialen Medien teilen

nospam@example.com (Thomas Hochstein) — Wed, 08 Apr 2020 10:00:00 +0000

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.

Blogbeiträge in sozialen Medien teilen

Es geht also nichts über das eigene Blog - aber wie macht man dessen Inhalte sichtbar? Die Vernetzung über Links und Blogrolls oder gar Blogverzeichnisse funktioniert allenfalls innerhalb der “Blogosphäre”, erreicht aber den durchschnittlichen Internetnutzer nicht; und wenn man Leser gefunden hat, können diese das Blog natürlich über einen RSS-Feed “abonnieren” oder verfolgen, aber auch RSS (und Atom) gerät zunehmend in Vergessenheit. Das lässt sich nicht nur an der Einstellung des Google Readers 2013 (sieben Jahre ist das schon her!) erkennen, sondern auch am Wegfall der Unterstützung für diese Formate in populären Programmen wie Firefox.

Ein guter Weg ist daher die Ankündigung bzw. das Teilen der eigenen Beiträge in den proprietären sozialen Netzwerken, um auch deren Nutzer “abzuholen” und es ihnen zu ermöglichen, auf diese Weise dem eigenen Blog zu “folgen”. Das kann man selbst tun, man kann es automatisieren und man kann auch den Lesern einfache Möglichkeiten bieten, die Beiträge über ihre Accounts zu teilen; entsprechende “Sharing Buttons” gehören mittlerweile zum gewohnten Bild vieler Webpräsenzen.

Ein simpler Link ist aber auf Twitter alles anderen als ein Eye-Catcher, und Facebook erzeugt zwar eine ansehnliche Vorschau für Links, die man in seinen Status aufnimmt, doch auch das gelingt nicht immer optimal: die dort abgebildeten einleitenden Worte sind für einen Überblick über den Beitrag nicht unbedingt geeignet, und wenn ein Bild ausgewählt wird, dann passt es oft überhaupt nicht zum Link. Wie schön wäre es, wenn man bei Facebook Bild und Zusammenfassung selbst kontrollieren könnte und bei Twitter für seine Links ebenfalls eine Vorschau anzeigen könnte, wie man das von anderen Tweets - bspw. verschiedener Medien - kennt! Und all das kann man; auch und gerade mit Serendipity. Und man sollte es auch tun, jedenfalls dann, wenn man seine Beiträge in sozialen Medien teilen will.

Vorschaubilder für Links bei Twitter und Facebook (und anderswo)

Blogbeitrag, geteilt auf Twitter.

Das “Geheimnis” hinter den Bildern und Zusammenfassungen, mit der Twitter und Facebook (aber auch andere Dienste wie bspw. Tumblr oder Slack) Links ersetzen bzw. aufhübschen, ist das Open Graph Protocol, das Twitter in der Form von Twitter Cards leicht abwandelt. All das, was man in diesen Vorschaublocks sieht, findet sich unsichtbar im <head>-Abschnitt der jeweiligen Webseite, die verlinkt wurde. Dort finden sich spezielle <meta>-Tags, in denen Titel, Beschreibung, Link, Bild usw. hinterlegt sind, die in der Vorschau erscheinen sollen. Die Einzelheiten dazu - mit vielen Beispielen und Empfehlungen, bspw. zu Bildgrößen und Länge der einzelnen Textelemente - habe ich vor vier Jahren schon einmal in dem Beitrag “Open Graph Protocol und Twitter Cards” hier im Blog erläutert. (Alle Links sind noch einmal am Ende des Beitrags zusammengefasst.)

Blogbeitrag, geteilt auf Facebook.

`serendipity_event_social`

Die notwendigen Einträge kann das Serendipity-Plugin serendipity_event_social setzen, das sich über den Plugin-Manager Spartacus installieren lässt.

Ein beitragsspezifisches Bild.

Das verwendete Bild kann man in Serendipity für jeden Eintrag unter den “Erweiterten Optionen” des Eintrags gesondert auswählen. Wird hier keine Auswahl getroffen, verwendet Serendipity bei den Themes Timeline und Photo die - nur - dort vorgesehenen Titelbilder (bzw. “featured images”) für jeden Eintrag; ansonsten wird das erste im Eintrag vorkommende Bild verwendet. Gibt es auch dort kein Bild, greift Serendipity auf das in der Plugin-Konfiguration definierte Standardbild zurück.

`serendipity_event_metadesc`

Die für den Titel und die Beschreibung verwendeten Texte kann serendipity_event_social allerdings nicht setzen; es greift standardmäßig vielmehr auf den Titel des Beitrags und die ersten 200 Zeichen des Beitrags zurück. Auch das lässt sich aber steuern, und zwar mit dem Plugin serendipity_event_metadesc.

Die Eingabefelder des Metadesc-Plugins in der Beitragsbearbeitung.

Dieses Plugin bietet für jeden Eintrag - ebenfalls in den “Erweiterten Optionen” - die Möglichkeit, die <meta>-Tags Description und Keywords zu setzen, auf die übrigens auch Suchmachinen wie Google für die Suche wie auch die Darstellung der Suchergebnisse zugreifen. Es empfiehlt sich daher ohnehin, dieses Plugin zu installieren und für die eigenen Blogbeiträge ein knackiges Summary zu hinterlegen. Auf die dort eingegegeben Description greift auch serendipity_event_social zurück und übernimmt sie für die Open Graph-Einträge.

Sharebuttons mit `serendipity_event_social`

Vorschaubilder und passende Beschreibungen auf Twitter und Facebook sind ja schon toll - noch toller wäre es aber, wenn man selbst (und die werte Leserschaft!) Blogbeiträge einfach und datenschutzkonform auf Facebook, Twitter und anderen sozialen Medien teilen könnte, am besten, ohne den Eintragstitel und den Link von Hand kopieren zu müssen. Kurzum, entsprechende Buttons wären schön, wie die sozialen Netzwerke sie anbieten, aber doch bitte möglichst ohne das Nachladen irgendwelchen Codes von dort, der dann wer-weiß-welche Informationen über die Besucher des eigenen Blogs nach dort übermittelt. Dafür gibt es von Heise online das Shariff-Projekt, das “Teilen”-Buttons für soziale Netzwerke ohne jede Datenübermittlung an dieselben anbietet (bis man darauf klickt, logischerweise - denn dann will man ja gerade, äh, Daten teilen).

Und auch Shariff kann man mit serendipity_event_social in das eigene Blog einbinden - das ist sogar der primäre Anwendungsbereich dieses Plugins.

Die Konfiguration des Sharebuttons-Plugins.

In der Pluginkonfiguration lassen sich die sozialen Netzwerke auswählen, für die “Teilen”-Buttons am Ende jedes Beitrags angezeigt werden sollen - soweit das Shariff-Projekt entsprechende Buttons anbietet. Außerdem kann man auswählen, ob die Buttons nur unter den einzelnen Einträgen erscheinen sollen oder auch auf Übersichtsseiten wie der Startseite des Blogs, den Archivseiten oder Suchergebnissen unter jedem Beitrag angezeigt werden sollen.

Hier wird auch das bereits weiter oben angesprochene Fallback-Bild konfiguriert, das als Vorschaubild in den sozialen Medien angezeigt wird, wenn im Beitrag kein Bild angegeben ist bzw. sich keines dort findet. Für die Twitter-Nutzer kann man zudem noch das eigene Twitter-Handle an den geteilten Text anhängen lassen.

Außerdem bietet das Shariff-Projekt für diejenigen sozialen Netzwerke, die das unterstützen, einen Zähler an, wie oft der Beitrag dort bereits geteilt wurde; das ist im Wesentlichen allerdings nur noch Facebook. Außerdem braucht es dazu ein Backend; die dazu notwendige Software kann man selbst installieren, oder man greift auf die von Serendipity-Entwickler onli angebotene Installation auf https://onli.columba.uberspace.de/s9y_shariff/ zurück, die im Plugin auch als Default eingestellt ist.

Beiträge automatisch teilen

Noch besser als auf Knopfdruck geteilte Beiträge mit passendem Bild und Text sind nur automatisch geteilte Beiträge - und auch das geht, allerdings nicht mehr mit Facebook, jedenfalls nicht auf der eigenen Profilseite, sondern nur auf “Facebook Pages”, also quasi Fanseiten.

Für diese Aufgabe eignen sich eine Vielzahl von Diensten, die sich die Vernetzung verschiedener Apps zur Aufgabe gemacht haben; zu den bekannteren zählen bspw. “If This Then That” (IFTTT) oder Zapier. Allen diesen gemeinsam ist, dass man einen Auslöser (Trigger) mit einer Aktion verbindet (und ggf. noch Filter dazwischenschaltet). Man beauftragt den Dienst bspw., regelmäßig den RSS-Feed des eigenen Blogs abzurufen und immer dann, wenn sich dort ein neuer Beitrag findet, einen Tweet oder einen Facebook-Post auf der eigenen Fanseite zu veröffentlichen (oder sonst etwas zu tun).

`serendipity_event_twitter`

Soweit man jedoch mit automatischen Tweets auf Twitter zufrieden ist - weil man bspw. keine Facebook-Fanseite hat und die Beiträge auf der eigenen Profilseite gezwungenermaßen von Hand veröffentlichen muss -, geht das auch mit Serendipity-Bordmitteln: das Microblogging-Plugin serendipity_event_twitter kündigt neue Beiträge sogar ohne die bei den Automatisierungsdiensten übliche Verzögerung im Bereich von Minuten (oder halben Stunden) sofort an!

Die Vielzahl der Einstellungen und Möglichkeiten dieses Plugins würde allerdings die Grenzen dieses Beitrags sprengen, weshalb ich mich stattdessen auf einen Verweis auf die mit dem Plugin mitgelieferte mehrsprachige Dokumentation verweise, die sich aus der Plugin-Verwaltung von Serendipity abrufen lässt und auch auf Github eingesehen werden kann (allerdings dann in “rohem” HTML). Für einen ersten Überblick genügt vielleicht auch der folgenden Screenshot.

Screenshot der Dokumentation des Twitter-Plugins.

Zusammenfassung

Wer seine Blogbeiträge einfach und mit einer schicken Vorschau versehen auf Twitter, Facebook und Co teilen möchte. installiert sich die Plugins serendipity_event_social und serendipity_event_metadesc und füllt im Beitragseditor die Felder für die Meta-Beschreibung und ggf. das Eintragsbild aus; sollen die Veröffentlichungen bei Twitter automatisch erscheinen, kommt noch die Installation und Konfiguration von serendipity_event_twitter dazu. Das war’s!

Selbstverständlich gibt es auch für andere Blogsysteme und CMS - wie Wordpress - entsprechende Plugins, und selbstverständlich kann man Open Graph und Twitter Cards sowie Shariff auch für die eigene Homepage nutzbar machen, sei es von Hand oder durch entsprechende Ergänzungen des verwendeten CMS oder static site generators. Wie das aussehen kann, kann man sich bspw. auf meinen Webseiten ansehen.

Zusammenfassende Linkliste

Hier noch einmal die wichtigsten Links zusammengestellt:

Grundlagen

Open Graph Protocol und Twitter Cards bei Netz - Rettung - Recht
The Open Graph protocol
Best Practices for Facebook Sharing (facebook for developers)
Optimize Tweets with Cards bei Twitter developers

Shariff - sichere Sharing-Buttons bei Netz - Rettung - Recht
Shariff-Repository bei Github
Datenschutz und Social Media: Der c’t Shariff ist im Einsatz bei heise online

Automatisierungsdienste

IFTTT (“If This Then That”)
Zapier

Serendipity-Plugins

Serendipity-Plugin Sharebuttons (serendipity_event_social)
Serendipity-Plugin HTML Meta-Tags (serendipity_event_metadesc)
Serendipity-Plugin Microblogging (serendipity_event_twitter)

Titelbild © TeraVector - stock.adobe.com

Ein Serendipity-Testblog auf dem aktuellen Stand halten

nospam@example.com (Thomas Hochstein) — Fri, 14 Apr 2017 13:45:00 +0000

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:

#!/bin/bash
cd /var/www</p>
<p>echo “——> Save config, plugins, themes and uploads …”
tar -czf s9y-testblog-backup.tgz s9y-testblog/serendipity_config_local.inc.php s9y-testblog/.htaccess s9y-testblog/plugins/* s9y-testblog/templates/* s9y-testblog/uploads/*</p>
<p>echo “——> Downloading …”
wget https://github.com/s9y/Serendipity/archive/master.zip</p>
<p>echo “——> Unzipping … (to Serendipity-master/)”
unzip master.zip</p>
<p>echo “——> Deleting current installation …”
rm -r s9y-testblog
echo “——> Restore config, plugins, themes and uploads …”
tar -xzf s9y-testblog-backup.tgz
echo “——> Install new files …”
cp -ar Serendipity-master/* s9y-testblog/
echo “——> Cleanup …”
rm master.zip
rm s9y-testblog-backup.tgz
rm -r Serendipity-master/</p>
<p>echo “——> Log last commit”
curl https://api.github.com/repos/s9y/Serendipity/commits/master -H “Accept: application/vnd.github.v3.sha” > s9y-testblog/COMMIT-ID

Das Script setzt voraus, dass das Testblog in /var/www/s9y-testblog installiert wurde; Pfade müssen ansonsten angepasst werden. Es sichert die lokale Konfiguration (einschließlich einer bestehenden .htaccess-Datei) sowie die Verzeichnisse für Plugins, Themes und die Mediendaten, bevor es die Dateien aus dem aktuellen Master-Branch lädt; die ZIP-Datei wird dann nach Serendipity-master entpackt. Danach wird das alte Testblog-Verzeichnis gelöscht; dann werden die gesicherten Dateien einkopiert und schließlich der Inhalt des Master-Branches überkopiert. Diese Reihenfolge ist wichtig, damit nicht eventuelle Updates von Plugins oder Templates, die mit dem Serendipity-Kern verteilt werden, durch das eingespielte Backup überschrieben werden. Am Schluss werden temporäre Dateien gelöscht und die Commit-ID des aktuellen HEAD des Master-Branches in einer Datei COMMIT-ID gespeichert. (Klar, da gibt es eine Race-Condition, weil möglicherweise jemand zwischen dem Laden der Daten und der Speicherung der Commit-ID neue Commits gepushed haben kann - für meine Zwecke reicht das aber.)

Alternativ kann man sich natürlich das Löschen und Neuaufsetzen sparen und einfach nur die neuen Dateien überkopieren; so lässt sich auch der Upgrade-Pfad testen. Das ginge dann vereinfacht so:

#!/bin/bash
cd /var/www</p>
<h1 id="log-last-commit">Log last commit</h1>
<p>curl https://api.github.com/repos/s9y/Serendipity/commits/master -H “Accept: application/vnd.github.v3.sha” > s9y-testblog/COMMIT-ID</p>
<h1 id="update">Update</h1>
<p>wget https://github.com/s9y/Serendipity/archive/master.zip
unzip master.zip
cp -ar Serendipity-master/* s9y-testblog/
rm master.zip
rm -r Serendipity-master/

Logfile-Auswertung mit AWStats

nospam@example.com (Thomas Hochstein) — Fri, 02 Sep 2016 20:00:00 +0000

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.

Es ist auch gar nicht so viel Arbeit, damit einen ganzen Haufen Websites statistisch zu erfassen - wobei ich das folgende als konzeptionelles Beispiel verstanden sehen möchte, nicht als copy&paste-fähige Anleitung. Man sollte sich bspw. gut überlegen, ob man die Webserver-Logs wirklich weltweit lesbar haben möchte oder nicht lieber anderweitig dafür sorgt, dass AWStats auf sie zugreifen kann.

Ein Logfile pro virtual host

Man definiert im jeweiligen virtual host ein weiteres CustomLog, bspw. /var/log/awstats/$domain.log, wobei $domain natürlich durch einen passenden Bezeichner zu ersetzen ist. Dabei sollte man daran denken, dort auch das Standard-Logfile, zumeist also wohl /var/log/apache2/access.log, erneut anzugeben, weil der Apache sonst nicht zusätzlich in das weitere Logfile schreibt, sondern nur noch nach dort.

Alternativ lässt man die Webserver-Logs nicht in eine Datei schreiben, sondern in ein Script pipen, das dann die eingehenden Logzeilen je nach Domain bzw. Hostnamen in der jeweils passenden Datei speichert - wie auch immer.

Die zusätzlichen Logfiles müssen für AWStats lesbar sein!

Eine AWStats-Konfigurationsdatei pro virtual host

Dann legt man sich für jede Domain (respektive jeden Hostname, respektive jeden virtual host) eine passende Konfigurationsdatei awstats.$domain.conf an (wobei man $domain jeweils durch eine passende Bezeichnug ersetzt) - die Konfigurationsdatei kann im selben Verzeichnis wie das Script liegen, in /etc/awstats, in /usr/local/etc/awstats, direkt in /etc oder auch in /etc/opt/awstats. Legt man die Konfiguration im selben Verzeichnis wie das Script an und will man ebendieses auch über den Webserver aufrufen, empfiehlt es sich, den Zugriff auf die Konfiguration in einer .htaccess-Datei zu sperren:

<FilesMatch "\.(conf|txt)$">
 order allow,deny
 deny from all
</FilesMatch>

Für Apache 2.4 ist diese Syntax bekanntermaßen anzupassen.

Statistik erstellen und im Web mit AWStats anschauen

Danach muss man das Sript nur noch aufrufen: perl /path/to/awstats.pl -config=$domain -update, wobei freilich statt /path/to/ der richtige Pfad und statt $domain die zuvor für den Namen der Konfigurationsdatei vergebene Kennung stehen muss. Voilà.

Die fertige Statistik lässt sich dann durch Aufruf von http://domain.example/cgi-bin/awstats.pl?config=$domain anzeigen, wenn denn der Webserver von domain.example entsprechend konfiguriert ist. “Oberhalb” von cgi-bin kann man sich dann noch eine Startseite mit Links zu den einzelnen Statistiken basteln.

Regelmäßige Aktualisierung der Statistik per Cronjob

Per Cronjob (bspw. in /usr/local/bin/do-webstats.sh) lassen sich dann täglich (stündlich, …) alle Statistiken aktualisieren:

#!/bin/dash
for i in $domain1 $domain2 $domainX; do
  echo "--- $i"
  perl /path/to/awstats.pl -config=$i -update
done

Rotation der zusätzlich für AWStats angelagen Logfiles

Und wenn man die - in unserem Beispiel in /var/log/awstats/ zusätzlich angelegten Logfiles nicht ins unendliche wachsen lassen möchte, sollte man auch logrotate noch mit einer passenden Konfiguration versehen, bspw. in /etc/logrotate.d/awstats:

/var/log/awstats/*.log {
    weekly
    missingok
    rotate 4
    compress
    delaycompress
    notifempty
    # die Logs muessen so erzeugt werden, dass AWStats sie lesen kann!
    create 644 root adm
    sharedscripts
    postrotate
    /etc/init.d/apache2 reload > /dev/null
        endscript
        prerotate
            /usr/local/bin/do-webstats.sh
        endscript
}

Für meine Zwecke scheint mir das doch weitgehend auszureichen - vielleicht auch deshalb, weil ich die sonstigen vielfältigen Möglichen, die bspw. Piwik bietet, nicht recht verstanden habe und/oder nicht nutze.

letsencrypt jenseits des Webservers

nospam@example.com (Thomas Hochstein) — Tue, 30 Aug 2016 14:30:00 +0000

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.

In der Folge stelle ich die Vorgehensweise ausgehend von einem Debian-Jessie-System aus vor.

Erhalt des Zertifikats

Am einfachsten ist das, wenn unter jedem Hostnamen auch ein Webserver erreichbar ist; dann kann nämlich einfach das webroot-Plugin verwendet werden. Ist das nicht der Fall, kommen bspw. das manual-Plugin oder das external-Plugin in Betracht.

Installation des Zertifikats

Das bereits - für den Webserver - vorhandene oder neu erhaltene Zertifikat und der zugehörige Schlüssel ( Key), die üblicherweise im Verzeichnis /etc/letsencrypt/live/domain.example/ liegen, können nun eingebunden werden - entweder das Zertifikat und die ganze Zertifikatskette mit allen Zwischenzertifikaten zusammen in einer Datei (fullchain.pem), oder das Zertifikat (cert.pem) und die Zwischenzertifikate (chain.pem) getrennt, je nachdem, was die Applikation unterstützt.

Nicht immer ist es aber ohne weiteres möglich, unmittelbar auf die Dateien in /etc/letsencrypt/live/domain.example/ zuzugreifen, die root:root gehören und aufgrund der Verzeichnisrechte auch nur für root lesbar sind. Manche Programme (bspw. der Mailserver Exim) greifen nämlich auf die Zertifikate zu einem Zeitpunkt zu, zu dem sie bereits keine Root-Rechte mehr haben; und es erscheint wenig tunlich, sie in die Gruppe root aufzunehmen oder gar Zertifikat und Key weltweit lesbar zu machen. Andere Programme wiederum haben ausgesprochen strikte Vorstellungen darüber, welchem Benutzer und/oder welcher Gruppe die Dateien “gehören” müssen und wie die Zugriffsrechte auszusehen haben (so z.B. der Newsserver INN, der erwartet, dass der Key ausschließlich für den User news lesbar ist). In diesen Fällen wird es m.E. unausweichlich sein, Kopien der Zertifikate und des Keys mit den passenden Rechten anzulegen.

Dovecot

Der POP3- und IMAP-Server Dovecot greift als root auf die Zertifikate zu und kann - jedenfalls in seiner in Debian Jessie enthaltenen Version 2.2.13 - die Zertifikatskette (fullchain.pem) verarbeiten. Es genügt also, Zertifikat und Key einzubinden und die Serverkonfiguration neu einzulesen (service dovecot reload).

Exim

Anders sieht es mit dem SMTP-Server Exim aus. Dieser gibt seine Root-Rechte auf, bevor er auf die TLS-Zertifikate zugreift. Immerhin kommt auch er mit fullchain.pem klar.

Eine Möglichkeit ist es, Zertifikat und Key in ein passendes Verzeichnis zu kopieren und dann Eigentümer und Rechte (644!) anzupassen, bspw. so:

cd /etc/exim4
mkdir certs 
cp /etc/letsencrypt/live/domain.example/fullchain.pem /etc/exim4/certs/
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/exim4/certs/
service exim4 restart
chown Debian-exim:Debian-exim /etc/exim4/certs/
chown Debian-exim:Debian-exim /etc/exim4/certs/*
chmod 644 /etc/exim4/certs/*

Ein solches Vorgehen wird dann auch bei jeder Erneuerung der Zertifikate erforderlich (s.u.)!

Danach genügt es, die Serverkonfiguration neu zu laden (service exim4 reload) und sich dann zu Testzwecken auf Port 25 zu verbinden und nach dem EHLO ein STARTTLS abzusetzen.

INN

INN stellt - jedenfalls in der in Debian Jessie enthaltenen Version 2.5.4 - ganz besondere Ansprüche: jedenfalls der Key muss für den Benutzer news lesbar sein, und er benötigt cert.pem und chain.pem getrennt.

Umsetzen könnte man das bspw. so:

cd /etc/news
mkdir certs 
cp /etc/letsencrypt/live/domain.example/cert.pem /etc/news/certs/
cp /etc/letsencrypt/live/domain.example/chain.pem /etc/news/certs/
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/news/certs/
chown news:news /etc/news/certs/*
chmod 600 /etc/news/certs/*

Auch hier muss man dieses Vorgehen für eine Erneuerung der Zertifikate im Blick behalten (s.u.).

Ein Einlesen der inn.conf später (service inn2 restart) sollte dann alles funktionieren wie geplant.

Zertifikat-Updates

Die nunmehr im Dateisystem verstreuten Zertifikatskopien müssen nach jeder Erneuerung des Zertifikats gleichfalls erneuert werden, damit nicht ein ungültiges Zertifikat ausgeliefert wird. Sinnvollerweise geschieht das ebenso automatisiert wie die Erneuerung des Zertifikats; hilfreich dabei die Möglichkeit, letsencrypt (bzw. certbot) mittels --post-hook nach einem Zertifikatsaustausch ein Script ablaufen zu lassen.

Exim

Man könnte sich daher bspw. eine Datei /usr/local/bin/certbot-exim4-renew.sh mit folgendem Inhalt anlegen:

#!/bin/dash
cp /etc/letsencrypt/live/domain.example/fullchain.pem /etc/exim4/certs/
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/exim4/certs/
service exim4 reload

Dazu passt dann ein Cron-Eintrag der folgenden Art:

certbot certonly --quiet -n --webroot -w /var/www/domain.example -d domain.example --keep-until-expiring --post-hook /usr/local/bin/certbot-exim4-renew.sh

Damit wird versucht, das Zertifikat für diesen Hostnamen (domain.example) zu erneuern, jedoch nur, wenn es der Erneuerung bedürftig ist.

Der Aufruf sollte in der Crontab zeitlich vor dem allgemeinen Aufruf certbot renew --quiet erfolgen, damit erst das spezielle Zertifikat aktualisiert (und ggf. umkopiert) wird und danach die übrigen.

INN

Für den INN sähe diese Lösung analog mit einer Datei /usr/local/bin/certbot-inn2-renew.sh so aus:

#!/bin/dash
cp /etc/letsencrypt/live/domain.example/cert.pem /etc/news/certs
cp /etc/letsencrypt/live/domain.example/chain.pem /etc/news/certs
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/news/certs
cd /etc/news/certs
chown news:news *.pem
chmod 600 *.pem
service inn2 reload

Der Cron-Eintrag wäre dann entsprechend:

certbot certonly --quiet -n --webroot -w /var/www/domain.example -d domain.example --keep-until-expiring --post-hook /usr/local/bin/certbot-inn2-renew.sh

Auch dieser Eintrag muss zeitlich vor dem allgemeinen Aufruf certbot renew --quiet liegen.

Und ihr?

So richtig optimal erscheinen mir diese Lösungen noch nicht. Gibt es bessere Ideen? Andere Erfahrungen?

Nutzt ihr letsencrypt noch für andere Dienste als die oben genannten?

An Euren Erfahrungen und Lösungen wäre ich interessiert und freue mich daher über Kommentare, Hinweise und Ergänzungen.

Open Graph Protocol und Twitter Cards

nospam@example.com (Thomas Hochstein) — Thu, 28 Apr 2016 05:45:00 +0000

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.

Open Graph Protocol

Entwickelt von Facebook bietet das Open Graph Protocol u.a. die Möglichkeit, zu kontrollieren, welche Daten Facebook beim “Teilen” der Seite

für die Überschrift (“title”),
als Teaser (“description”) und
als Vorschaubild (“image”),

verwendet, und außerdem

die Art der Seite (Webseite, Artikel, Profilseite, Seite über einen Film oder Song, …),
die kanonische URL,
die verwendete(n) Sprache(n),
…

anzugeben, indem entsprechende <meta>-Tags in den Kopfbereich (<head>...</head>) des Webdokuments eingefügt werden.

Diese haben eine Form à la <meta property="og:title" content="Alles über das Open Graph Protocol" /> und können natürlich durchaus automatisch erzeugt werden - so machen das die Blogsysteme, wenn sie denn diese Funktionalität bieten. Die Zeichenfolge og steht dabei für “Open Graph”, und der nach einem Doppelpunkt folgende Bezeichner gibt an, welche Eigenschaft in der Folge näher beschrieben wird.

Definition und ein Beispiel

Die komplette Definition des Protokolls findet sich natürlich online: The Open Graph protocol

Ein Beispiel für die konkrete Anwendung bietet bspw. die Stuttgarter Zeitung, deren CMS entsprechende Metadaten (und offenbar direkt auch ein angepasstes Bild) generiert, hier für den Artikel “Manfred Rommel ist tot”:

<meta property="og:type" content="article" />
<meta property="og:title" content="Ex-OB von Stuttgart: Manfred Rommel ist tot - Stuttgarter Zeitung" />
<meta property="og:image" content="http://www.stuttgarter-zeitung.de/media.facebook.cea3625e-2911-40c9-9c88-68af6718f64f.normalized.jpg" />           
<meta property="og:description" content=" Der frühere Stuttgarter Oberbürgermeister Manfred Rommel (CDU) ist tot. „Wir haben einen großen Oberbürgermeister und einen ganz besonderen Bürger verloren. Die Stadt ist in tiefer Trauer“, würdigte Fritz Kuhn (Grüne) den früheren OB. " />
<meta property="og:site_name" content="stuttgarter-zeitung.de">
<meta property="og:section" content=" - Stuttgart"> 
<meta property="og:locale" content="de_DE">

Es handelt sich dabei um einen article, der einen bestimmten title und eine description hat, die dann als Teaser ausgegeben wird. Außerdem wird ein Bild (image) in geeigneter Größe übermittelt; der Name der Website, deren Unterbereich (section) und die Angabe der Sprache sollen auch nicht fehlen.

So sieht das dann bei Facebook aus:

Artikel aus der Stuttgarter Zeitung, geteilt auf Facebook

Probieren geht über Studieren

Facebook bietet zum Ausprobieren einen Debugger an. Der zeigt nicht nur, welche Informationen aus den Metadaten extrahiert wurden, sondern auch, wie das Ergebnis voraussichtlich aussehen wird.

Zudem wird auf diese Weise - wichtig! - der interne Bild-Cache gelöscht. Hat man nämlich einmal einen Link geteilt, wird das Vorschaubild gecached; versucht man ihn nach dem Ändern des Bildes erneut zu teilen, erscheint daher wieder das alte Bild. Auch hier kommt der Debugger zur Hilfe.

Hinweise und Tipps für die eigene Anwendung

Bei der Auswahl der Texte für Überschrift und Teaser und des Vorschaubilds sollte man u.a. folgendes beachten:

Die Länge der Überschrift begrenzt Facebook bei mehr als 100 Zeichen auf 88 Zeichen. Am besten sollte sie nicht länger als 60-90 Zeichen werden.
Auch der Teaser ist beschränkt auf maximal 300 Zeichen, danach wird er von Facebook verkürzt.
Überschrift (“title”) und Teaser (“description”) können, müssen aber inhaltlich nicht den entsprechenden HTML-Elementen (<title>...</title> und <meta name="description" content="..." />) entsprechen.
Bilder mit Abmessung ab 600 x 315 px werden als große Bilder im Querformat angezeigt. Empfohlen werden für diesen Zweck Bilder ab 1.200 x 630 px - im Format 1.91:1, wenn möglich.
Alternativ kann ein kleines Bild verwendet werden, das dann nicht über, sondern links neben dem Text erscheint.
Kleiner als 200 x 200 px dürfen die Bilder nicht sein.
Beschnitten werden Bilder ggf. an den Seiten - graphische Elemente oder Text also am besten zentrieren!
Die Maximalgröße für Bilder liegt bei 8 MB. Aber auch hier ist natürlich weniger immer mehr!

Links zu weiteren Tipps sind am Ende des Beitrags gesammelt.

Nicht vergessen: bei Änderungen des Vorschaubildes über den Debugger den Bild-Cache aktualisieren lassen! Das betrifft allerdings nur neu geteilte Beiträge; in bestehenden Einträgen verbleibt das alte Bild.

Twitter Cards

Es wäre jetzt offenkundig viel zu einfach, wenn Twitter, das andere große Social Network, die Open-Graph-Daten von Facebook ebenfalls auswerten würde. Aber nein! Das geht natürlich keineswegs. Da muss etwas eigenes her. Twitter hat deshalb stattdessen die Twitter Cards erfunden.

Ganz so schlimm ist es aber nicht - immerhin werden Überschrift, Teaser und das Bild aus den Open-Graph-Daten übernommen, wenn man sie nicht nochmals angibt. Freilich kann man diese Einträge auch für Facebook und Twitter getrennt setzen und so ggf. unterschiedliche Schwerpunkte für Twitter-Follower und Facebook-Freunde schaffen. Twitter bietet zudem ebenfalls verschiedene Arten von Karten an, ähnlich wie Facebook unterschiedliche Typen von Open-Graph-Objekten kennt; zumeist dürfte die “Summary”-Card aber die richtige Wahl sein.

Einen Unterschied gibt es zu Facebook: die Nutzung von Twitter Cards muss für jede Website beim ersten Mal freigeschaltet werden, was über den Validator (s.u.) möglich ist.

Definition und ein Beispiel

Auch für Twitter Cards gibt es natürlich eine Dokumentation: Twitter Cards

Das oben bereits verwendete Beispiel aus der Stuttgarter Zeitung sieht dann - für Twitter - im Quellcode so aus:

<meta name="twitter:card" content="summary">
<meta name="twitter:site" content="@StZ_News">

Für den Rest verlässt die Stuttgarter Zeitung sich auf die Open-Graph-Daten.

Das Ergebnis sieht dann wie folgt aus:

Artikel aus der Stuttgarter Zeitung, geteilt auf Twitter

Probieren geht über Studieren

Auch Twitter bietet einen Validator an. Dessen Nutzung ist insofern zumindest beim ersten Mal verpflichtend, weil darüber auch die Freischaltung der jeweiligen Website für Twitter Cards angestoßen wird, die für die erste Verwendung erforderlich ist.

Hinweise und Tipps

Twitter hat natürlich nicht soviel Platz wie Facebook - daher gilt:

Die Länge der Überschrift ist auf 70 Zeichen begrenzt.
Der Teaser darf nicht länger als 200 Zeichen werden.
Es ist möglich, entweder ein großes oder ein kleines Vorschaubild zu übermitteln; die Auswahl trifft Twitter nicht automatisch, vielmehr muss sich der Nutzer für eine Summary Card oder eine Summary Card with Large Image entscheiden.
“Große” Bilder müssen mindestens 280 x 150 px groß sein.
Alle Bilder dürfen maximal eine Dateigröße von 1 MB erreichen.

Werden title, description und image für Facebook und Twitter verwendet, müssen sie logischerweise den Vorgaben beider Unternehmen (insbesondere für die Länge bzw. die Abmessungen) genügen.

Weiterer Lesestoff

Kissmetrics Blog: What You Need to Know About Open Graph Meta Tags for Total Facebook and Twitter Mastery
Eine anwendungsorientierte Zusammenstellung der wesentlichen Informationen zur Nutzung von Open Graph und Twitter Cards

Open Graph und Facebook

The Open Graph protocol
Die komplette Definition des Protokolls mit einer Vielzahl weiterführender Links.
Facebook: Sharing Best Practices for Websites & Mobile Apps
Hier finden sich u.a. Angaben zu den Maximallängen und -größen für Texte und Bilder.
Facebooks Debugger
Tibor Martini: Facebook: Vorschaubilder neu einlesen und neue Vorschaubilder gezielt festlegen
Schnatterente: Facebook: Link-Vorschau (Bild) aktualisieren

Twitter Cards

Twitter Cards
Twitters Card Validator

PHP-FPM - jetzt mit mod_proxy_fcgi

nospam@example.com (Thomas Hochstein) — Tue, 26 Apr 2016 05:50:00 +0000

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.

PHP-FPM und `mod_proxy_fcgi` installieren

Unter Debian Jessie ist die Installation der Pakete hinreichend einfach:

apt-get install php5-fpm php5

Debian hinterlegt dabei die php.ini für die FastCGI-Prozesse unter /etc/php5/fpm/php.ini und die Konfiguration für FPM unter /etc/php5/fpm/php-fpm.conf, ergänzt u.a. um die Konfiguration installierter Module in /etc/php5/fpm/conf.d/, wie man das so kennt.

Im Verzeichnis /etc/php5/fpm/pool.d/ sind dann die einzelnen Pools definiert, die ebenfalls in die /etc/php5/fpm/php-fpm.conf inkludiert werden, standardmäßig nur der Pool des Benutzers www-data, unter dem der Webserver läuft.

`mod_proxy_fcgi` für PHP-FPM konfigurieren

Serverweit lässt sich PHP-FPM dann wie folgt in einer neuen Datei /etc/apache2/conf-available/php5-fpm.conf konfigurieren:

<IfModule mod_proxy_fcgi.c>
    <Proxy "unix:/var/run/php5-fpm.sock|fcgi://php-fpm">
        # we must declare a (any) parameter in here 
        # or it won't register the proxy ahead of time
        ProxySet disablereuse=off
    </Proxy>
    <FilesMatch ".+\.php$">
        SetHandler proxy:fcgi://php-fpm
    </FilesMatch>
</IfModule>

Auf diese Weise werden auf .php endende Dateien an den darüber definierten Prxoy durchgereicht. Wer will, kann stattdessen bspw. auch <FilesMatch ".+\.ph(p[345]?|t|tml)$"> verwenden, wie Sven das empfohlen hat; das deckt auch alle anderen gebräuchlichen Endungen für PHP-Scripts ab.

Standardmäßig sorgt Debian übrigens dafür, dass das - mitinstallierte - Modul mod_proxy nicht als forward proxy arbeitet; das ist in der Datei /etc/apache2/mods-available/proxy.conf konfiguriert und stellt also kein Problem dar.

Nach Aktivieren des Moduls und der Konfiguration vermittels a2enmod proxy_fcgi und a2enconf php5-fpm sowie einem Restart des Webservers (service apache2 restart) sollte PHP nun zur Verfügung stehen.

Pools für einzelne Benutzer einrichten

Um nun verschiedene Pools für verschiedene Benutzer einzurichten, bedarf es neben einer passenden Konfiguration des jeweiligen Pools in /etc/php5/fpm/pool.d/ und eines geänderten Aufrufs in jedem virtual host, der diesem Benutzer zugeordnet ist.

Am einfachsten kopiert man sich die bestehende Konfiguration für den Pool www und wandelt sie ab:

cd /etc/php5/fpm/pool.d
cp www.conf user1.conf
vim user1.conf

Folgende Teile der Konfiguration müssen ersetzt werden: der Name des Pools, user, group und listen:

; Start a new pool named 'user1'.
; the variable $pool can we used in any directive and will be replaced by the
; pool name ('user1' here)
[user1]

[...]

user = user1
group = users

[...]

listen = /var/run/php5-fpm-user1.sock

Selbstverständlich können auch andere, für diesen Pool spezifische Änderungen vorgenommen werden

Und danach bekommt der bspw. in /etc/apache2/sites-available/user1-domain.example konfigurierte virtual host noch folgende Ergänzung (zwischen <VirtualHost ...> und </VirtualHost>):

<IfModule mod_proxy_fcgi.c>
    <Proxy "unix:/var/run/php5-fpm-user1.sock|fcgi://php-fpm-user1">
        # we must declare a (any) parameter in here 
        # or it won't register the proxy ahead of time
        ProxySet disablereuse=off
    </Proxy>
    <FilesMatch ".+\.php$">
        SetHandler proxy:fcgi://php-fpm-user1
    </FilesMatch>
</IfModule>

In diesem virtual host kommuniziert der Apache also nicht mit dem FastCGI-Server über /var/run/php5-fpm.sock, sondern über /var/run/php5-fpm-user1.sock, und den haben wir ja anders konfiguriert. Ein service apache2 restart bzw. service php5-fpm restart später sollte die geänderte Konfiguration zur Verfügung stehen.

Soll PHP in mehreren virtual hosts unter derselben Benutzerkennung laufen, empfiehlt es sich, die o.g. Konfiguration in eine eigene Datei (bspw. /etc/apache2/sites-available/user1.fcgi) auszulagern und diese Datei dann in die virtual host-Konfiguration einzubinden:

Include /etc/apache2/sites-available/user1.fcg

Das spart nicht nur Tipparbeit, sondern erleichtert auch spätere Änderungen sehr.

Die Installation testen

Am einfachsten gestaltet sich der Test, wenn man im Webroot des Servers (Debian Jessie: /var/www/html/) und der einzelnen virtual hosts jeweils eine Datei test.php speichert, die nur phpinfo() aufruft:

<?php phpinfo(); ?>

In der Ausgabe von phpinfo() wird angezeigt, unter welchem Benutzer das Script ausgeführt wird.

Vielen Dank an Sven für den hilfreichen Tip!

SSL/TLS mit Let's Encrypt

nospam@example.com (Thomas Hochstein) — Mon, 11 Apr 2016 07:00:00 +0000

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.

Let’s Encrypt - die Prinzipien

Let’s Encrypt arbeitet kostenlos und veröffentlicht die verwendeten Schnittstellen. Es stellt eine CA zur Verfügung, die automatisch Zertifikate ausstellt, nachdem sie überprüft hat, dass der Anfragende die administrative Kontrolle über den entsprechenden Hostnamen hat - beispielsweise, indem Let’s Encrypt verlangt, dass eine bestehende Datei auf dem Webserver unter diesem Hostnamen hinterlegt wird. Die erstellten Zertifikate werden öffentlich gemacht; es kann also jeder jederzeit nachvollziehen, wann Let’s Encrypt welche Zertifikate erstellt hat.

Mittlerweile ist das Zwischenzertifikat von Let’s Encrypt nicht nur durch Let’s Encrypt selbst, sondern auch durch eine andere CA (IdenTrust) signiert und wird daher regelmäßig von den Browsern als vertrauenswürdig anerkannt. Von Let’s Encrypt ausgestellte Zertifikate werden also akzeptiert und führen nicht zu irgendwelchen Warnmeldungen. Sie gelten allerdings nur rund 90 Tage und müssen dann erneut werden.

Let’s Encrypt stellt Client-Software zur Verfügung, die den gesamten, einleitend dargestellten Workflow automatisiert, ermöglicht es aber auch, die notwendigen Schritte in beliebigem Umfang manuell nachzuvollziehen oder auch eigene Lösungen zu programmieren. Im vollautomatischen Modus erstellt Let’s Encrypt das notwendige Schlüsselpaar und den CSR, überprüft, dass der Antragsteller den Hostnamen kontrolliert, stellt das Zertifikat aus und speichert es, passt die Webserver-Konfiguration an und bindet das Zertifikat ein und kann auf Wunsch rechtzeitig vor Ablauf ein neues Zertifikat erstellen.

Let’s Encrypt und der Apache-Webserver unter Debian Jessie

Im Anschluss möchte ich einen weitgehend, aber nicht völlig automatisierten Ablauf zum Erstellen von SSL-Zertifikaten und deren Einbindung in einen Apache unter Debian Jessie darstellen. Es ist durchaus möglich, weit weniger auf Automatismen zu setzen; dann muss der Client auch nicht zwingend mit Root-Rechten laufen. Matthias Gutjahr schildert in seinem Blog eine Möglichkeit dafür; Dirk Deimeke hat eine weitere Alternative dargestellt. Beide Beiträge sind am Ende dieses Blogbeitrags verlinkt.

Installation

Ab Jessie, der derzeit stabilen Debian-Version, steht letsencrypt als Paket zur Verfügung, allerdings nur in den Backports. Wenn sich in der /etc/apt/sources.list also die Zeile deb http://ftp.debian.org/debian jessie-backports main findet, ist die Installation daher denkbar einfach:

apt-get -t jessie-backports install letsencrypt

Die umfangreichen Abhängigkeiten werden mitinstalliert.

Wer noch unter Wheezy arbeitet, benötigt etwas mehr Vertrauen in die Macher von Let’s Encrypt - und Platz für ein umfangreicheres Software-Paket (letsencrypt-auto), das u.a. eine komplette virtuelle Python-Umgebung mit sich schleppt:

cd /usr/local
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto --help

letsencrypt-auto akzeptiert dann denselben Input wie letsencrypt.

Zertifikat erstellen lassen

letsencrypt bietet eine ncurses-Oberfläche, die es ermöglicht, auf einige Kommandozeilen-Parameter zu verzichten und ggf. notwendige Abfragen im Dialog zu beantworten. Dazu gehört beim ersten Start u.a. die Angabe einer E-Mail-Adresse für eine mögliche Kontaktaufnahme und die Bestätigung der AGB, die erforderlich ist. Danach erstellt letsencrypt automatisch einen Account samt Schlüsselpaar, so dass weitere Aufrufe in der Regel ohne Interaktion ablaufen können.

Alle Daten werden standardmäßig unter /etc/letsencrypt/ abgelegt.

Der folgende Aufruf fordert ein Zertifikat für die Hostnamen domain.example und www.domain.example an, deren Dateien auf der Platte im Verzeichnis /var/www/domain.example (Webroot) liegen:

letsencrypt certonly --webroot -w /var/www/domain.example/ -d domain.example -d www.domain.example

Falls notwendig, werden Mailadresse und Zustimmung zu den AGB (“Terms of Service”, “TOS”) abgefragt und ein privater Schlüssel (bzw. das Schlüsselpaar) erstellt. Dann wird der CSR an Let’s Encrypt geschickt, temporär eine unter http://domain.example/ abrufbare Datei im Webroot erstellt und so geprüft, dass man wirklich die Kontrolle über diesen Hostnamen hat, das Zertifikat erstellt, unter /etc/letsencrypt/archive/domain.example/ gespeichert und ein Symlink von /etc/letsencrypt/live/domain.example/ nach dort erstellt.

Soll das Zertifikat für weitere Hostnamen gelten, können beliebig viele Folgen von -w webroot -d hostname angeschlossen werden. Es folgt jeweils auf das -w webroot die Angabe der Hostnames, die zu diesem Webroot gehören.

Zertifikat beim Apache einbinden

Eine minimale Konfiguration für den virtual host könnte im Apache 2.4 (Debian Jessie) so aussehen:

<VirtualHost *:443>
    ServerName domain.example
    ServerAlias www.domain.example

    DocumentRoot /var/www/domain.example

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/domain.example/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/domain.example/privkey.pem
</VirtualHost>

Der Apache 2.2, der mit Debian Wheezy ausgeliefert wird, muss Zertifikat und Zwischenzertifikat der CA getrennt ausliefern:

<VirtualHost *:443>
    [...]
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/domain.example/cert.pem
    SSLCertificateChainFile /etc/letsencrypt/live/domain.example/chain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/domain.example/privkey.pem
</VirtualHost>

Zertifikate erneuern

Folgender Cronjob prüft täglich um 4 Uhr morgens, ob ein Zertifikat erneuert werden muss, und nimmt diese Erneuerung automatisch vor, wenn sich der Ablaufzeitpunkt nähert:

00 4 * * * letsencrypt renew --keep-until-expiring

Weiterer Lesestoff

Let’s Encrypt: Getting Started
Wouter Verhelst im WEBlog — Wouter’s Eclectic Blog: Playing with Letsencrypt
Matthias Gutjahr im Sperrobjekt Weblog: Let’s Encrypt-Zertifikate manuell erzeugen
Dirk Deimeke in Dirks Logbuch: Let’s Encrypt …

Der eigene Webserver mit SSL/TLS

nospam@example.com (Thomas Hochstein) — Thu, 07 Apr 2016 05:50:00 +0000

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.

SSL-/TLS-Zertifikate und deren Prüfung

Das liegt darin, dass Verschlüsselung allein zumindest im Grundsatz nicht genügt - wichtig ist auch Authentifizierung, also die Überprüfung, ob man auch mit der richtigen Gegenstelle spricht oder sich ein Dritter, der “Man in the middle”, dazwischengehängt hat. Zu einer mittels SSL/TLS (in Zukunft: SSL als Sammelbegriff für beides) gesicherten Verbindung gehört daher - eigentlich - auch immer die Überprüfung des Zertifikats der Gegenstelle. Dazu muss man entweder den Fingerprint des Zertifikats kennen und prüfen - PGP/GPG lässt grüßen -, oder man begnügt sich damit, dass eine Zertifizierungsstelle die Echtheit des Zertifikats bestätigt hat (und hofft auf deren Sorgfalt; eine Hoffnung, die die Praxis bereits vielfach enttäuscht hat).

Will man selbst verschlüsselte Zugänge anbieten, genügt es für die meisten Dienste, ein selbst-signiertes Zertifikat zu erstellen und den Nutzern den Fingerprint mitzuteilen. In der Regel ist der Nutzerkreis selbstgehosteter Dienste nämlich überschaubar: der private Mailserver wird zum Versand und zum Mailabruf in der Regel nur selbst oder allenfalls von Familienmitgliedern und Freunden genutzt, die dem selbst-signierten Zertifikat dann vertrauen können. Nicht unüblich ist es auch, auf eine Zertifikatsprüfung zu verzichten und jedes präsentierte Zertifikat zu akzeptieren, also nur die Verschlüsselung zu nutzen und der Gegenstelle zu vertrauen. Das ist insofern nachvollziehbar, als es deutlich einfacher ist, (unverschlüsselten) Datenverkehr mitzulesen als sich als “Man in the middle” mit einem falschen Zertifikat in den verschlüsselten Datenstrom einzuklinken.

HTTPS im Speziellen

Bei Webdiensten liegt der Fall hingegen etwas anders: zumeist erfolgt der Zugriff für die Allgemeinheit - der nicht zwingend einer Absicherung durch Verschlüsselung bedürfte - über dieselbe “Domain” (ich verwende den Begriff hier umgangssprachlich; richtiger wäre “Hostname”) wie die Administration. Ein Blog, bspw., das unter http://meinblog.example/ zugänglich ist, wird meist über http://meinblog.example/admin/ verwaltet, nicht aber über http://admin.meinblog.example/. Ich muss also damit rechnen, dass auch die Allgemeinheit auf meine Webseiten über HTTPS zugreift, oder ich will das sogar erzwingen, damit ich nicht versehentlich Passwörter über eine ungeschützte Verbindung übertrage.

Dann habe ich aber ein Problem: mein selbst-signiertes Zertifikat ist den Besuchern der Webseite natürlich unbekannt, und Browser generieren für diesen Anwendungsfall zunehmend auffälligere Warn- und Fehlermeldungen, die einen Zugriff auf die Seite entweder ganz unterbinden oder doch arg erschweren und den Durchschnittsnutzer abschrecken (was ja auch Sinn der Sache ist).

Virtual Hosting

Zu diesem Problem der Fehlermeldungen bei selbst-signierten Zertifikaten kommt noch ein ein weiteres hinzu: es ist üblich, über einen Webserver (auf ein- und derselben IP-Adresse) eine Vielzahl von “Domains” (also getrennten Webseiten) anzubieten. Bei größeren Anbietern können das hunderte oder zigtausende Nutzer sein, die sich da auf einem Host tummeln, aber auch der private Nutzer hat vielleicht neben seiner Homepage unter meine-domain.example auch noch ein Blog unter blog.meine-domain.example oder will schlicht seine Webseiten sowohl unter meine-domain.example als auch unter www.meine-domain.example erreichbar machen. Das sind aber alles unterschiedliche Hostnamen, und da jedes SSL-Zertifikat angeben muss, für welchen Hostnamen es gültig ist, haben wir das nächste Problem: liefert der Webserver für www.meine-domain.example das Zertifikat für meine-domain.example aus, verfallen die Warnmeldungen im Browser nicht selten in eine noch schrillere Tonlage.

Es ist leider auch nicht so einfach, für jede “Domain” ein eigenes Zertifikat zu präsentieren. Der Zugriff auf solche virtual hosts erfolgt nämlich in der Weise, dass der Browser einen Header mitschickt, aus dem sich ergibt, auf welche “Domain” er zugreifen will. Für diesen Zugriff muss aber die verschlüsselte Verbindung schon stehen; andersherum weiss der Server beim Verbindungsaufbau noch nicht, welche “Domain” angefragt wird, und kann daher auch nicht das jeweils “richtige” Zertifikat ausliefern.

Was also tun?

Lösungswege

Über die Jahre habe ich verschiedene - allesamt mehr oder weniger unbefriedigende - Möglichkeiten getestet, um diesem Problem zu Leibe zu rücken.

Die eigene CA

Angefangen habe ich vor gut einem Jahrzehnt mit einer eigenen Zertifizierungsstelle, die meine SSL-Zertifikate signiert. Dann reicht es nämlich, das Stammzertifikat dieser Zertifizierungsstelle dem Browser (und ggf. dem Mailprogramm) als gültig unterzuschieben, und alle anderen Zertifikate werden automatisch akzeptiert. Das erleichtert zumindest einmal mir selbst (und Freunden und Bekannten, die mir ausreichend trauen) den Umgang mit verschiedenen Servern und ggf. verschiedenen Hostnamen, behebt aber nicht das Problem, dass das Zertifikat immer nur für einen Hostnamen (eine “Domain”) gültig ist, und hilft auch den Webseitenbesuchern nicht.

Ich habe mich daher in der Regel darauf beschränkt, HTTPS nur ergänzend anzubieten oder nur für solche Webseiten, die ausschließlich intern genutzt werden und sich nicht an die Allgemeinheit richten. Professionell geht aber fraglos anders.

SAN

Danach habe ich mich mit Subject Alternate Names, kurz SAN, vertraut gemacht. Es ist nämlich möglich, einem Zertifikat mitzugeben, dass es für mehr als einen Hostnamen gültig ist. Zum einen gibt es - nicht empfehlenswerte - sog. “Wildcard-Zertifikate”, die für alle Subdomains einer bestimmten Domain gültig sind, bspw. *.domain.example. Zum anderen gibt es SAN - zusätzliche Hostnamen, für die das jeweilige Zertifikat auch gilt. Die kann man bei der Erstellung des Zertifikats mit angeben.

Das funktioniert ganz gut, löst aber zum einen nicht das Problem der fehlenden allgemeinen Akzeptanz des Zertifikats und schafft zudem zwei neue Schwierigkeiten. Zum einen kann jeder Besucher durch Ansicht des Zertifikats feststellen, welche Webseiten auf dem Server sonst noch so gehostet werden (was nicht immer optimal ist), zum anderen braucht es für jede neue “Domain”, auf die auch per HTTPS zugegriffen werden soll, auch ein komplett neues Zertifikat.

SNI

Dem strukturellen Problem, dass der Server erst die verschlüsselte Verbindung aufbauen muss und danach erfährt, für welche “Domain” er das eigentlich tun soll, ist man mit Server Name Indication, kurz SNI, zu Leibe gerückt. Das ist eine Erweiterung des TLS-Protokolls, die es dem Client erlaubt, beim Verbindungsaufbau bereits mitzuteilen, aus welcher “Domain” er später Webseiten abrufen will, so dass der Server ihm dann das richtige Zertifikat präsentieren kann. So kann auch der Webserver für jede “Domain” ein eigenes Zertifikat anbieten.

Mittlerweile darf man davon ausgehen, dass SNI so verbreitet ist, dass man es im praktischen Betrieb voraussetzen kann: Firefox unterstützt es seit Version 2.0, der Internet Explorer seit Version 7 und Windows Vista (nicht unter Windows XP), und auch wget sollte das seit 2012 beherrschen.

Kommerzielle Zertifikate

Dies wiederum ermöglicht es, auf kommerzielle SSL-Zertifikate zurückzugreifen. Deren Anbieter lassen sich nämlich ihre Dienste bei “Wildcard-Zertifikaten” oder solchen mit einer Vielzahl von Hostnamen (oder auch bei erweiterter Validierung der “Domains”, für die das Zertifikat gelten soll) geradezu fürstlich bezahlen; Zertifikate für nur ein oder zwei Namen (also bspw. domain.example und www.domain.example) sind hingegen erschwinglich oder gar kostenlos. SNI macht es jetzt möglich, jeder “Domain” ihr eigenes günstiges Zertifikat zuzuweisen, bspw. von StartCom, einem Anbieter, der Zertifikate für maximal zwei “Domains” kostenlos abgibt (dann allerdings für den Widerruf eines kompromittierten Zertifikats Geld verlangt - nun ja).

So kann man dann allmählich vernünftig mit SSL arbeiten.

Die Zukunft: letsencrypt

Neuerdings befindet sich zudem mit Let’s Encrypt ein Anbieter am Start, der sich kostenloses, freies und massentaugliches SSL/TLS auf die Fahnen geschrieben hat:

Let’s Encrypt is a new Certificate Authority:
It’s free, automated, and open.

Dazu werde ich später mehr berichten.

SSL-Zertifikate und Apache

Nach der Theorie nun etwas Praxis: wie richte ich beim Apache-Webserver einen virtual hosts mit SSL ein?

Im Prinzip ist das recht einfach; Debian liefert bspw. eine entsprechende Konfiguration schon mit. Ich setze im Folgenden voraus, dass sowohl passende SSL-Zertifikate (mit dem zugehörigen private key in entschlüsselter Form, d.h. ohne Passwortschutz) vorhanden als auch virtual hosts grundsätzlich eingerichtet sind. Die Zertifikate speichere ich im Verzeichnis /etc/apache2/ssl.

Eine Basis-Konfiguration könnte dann - mit einem Zertifikat von StartCom - bspw. so aussehen:

<VirtualHost *:443>
    ServerName meine-domain.example
    ServerAlias www.meine-domain.example

    DocumentRoot /var/www/meine-domain.example

    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/meine-domain.example.crt
    SSLCertificateKeyFile /etc/apache2/ssl/meine-domain.example.key
    SSLCertificateChainFile /etc/apache2/ssl/sub.class1.server.ca.pem
</VirtualHost>

Will man alle Zugriff von HTTP auf HTTPS umleiten, kann man bspw. folgendes ergänzen:

<VirtualHost *:80>
    ServerName meine-domain.example
    ServerAlias www.meine-domain.example

    Redirect / https://meine-domain.example/
</VirtualHost>

Disclaimer

SSL/TLS, der Umgang mit Zertifikaten und die Konfiguration des Apache sind ein weites Feld, für das ich zudem kein Spezialist bin.

Dieser Beitrag will einen kurzen, knappen und daher notwendigerweise unvollständigen Überblick zu diesem Thema geben und zur eigenen Beschäftigung damit anregen. Ich habe daher manches vereinfacht, anderes weggelassen, wieder anderes - absichtlich oder unabsichtlich - ungenau dargestellt.

Dies ist kein Tutorial, und die am Schluss genannten Beispiele sind nicht zur 1:1-Übernahme via copy & paste geeignet.

Wenn sich Fehler eingeschlichen haben, bin ich über Kommentare dankbar - und auch Ergänzungen nehme ich natürlich gerne entgegen.

Backups in die Cloud (duply und S3)

nospam@example.com (Thomas Hochstein) — Tue, 29 Mar 2016 13:00:00 +0000

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$.

Backup mit duply in einen AWS S3-“Bucket”

Für verschlüsselte und komprimierte Backups bieten sich duplicity und duply an; die grundsätzliche Einrichtung von duply habe ich bereits 2011 beschrieben. Zusätzlich benötigen wir für das Cloud-Backup noch dreierlei: einen S3-“Bucket”, in dem die Backups landen sollen, Zugangsdaten für diesen “Bucket”, und eine Anpassung der duply-Konfiguration.

Für die Nutzung der Amazon Web Services (AWS) ist eine Anmeldung dort erforderlich. Außerdem empfiehlt es sich sehr, nicht mit den Daten des Haupt-Accounts auf unseren S3-“Bucket” zuzugreifen, sondern mit einem extra dafür erzeugten Nutzeraccount, der dann auch nur auf diesen “Bucket” zugreifen kann. Dazu dient das Identity and Access Management (IAM).

AWS-Konfiguration

Fangen wir an mit der Anlage des S3-Speicherplatzes. Dazu genügt es, in der S3 Console mit Klick auf Create einen neuen “Bucket” anzulegen. Der vergebene Name muss AWS-weit eindeutig sein, es empfiehlt sich daher etwas in der Form accountname-backup-servername o.ä. Dabei muss dieser Name eine gültige Subdomain darstellen (vgl. die AWS-Dokumentation) und er sollte - um spätere Schwierigkeiten beim Zugriff zu vermeiden - keine Punkte enthalten. (Mit duplicity und den zugehörigen Libraries unter Debian Wheezy hatte ich keine Zugriffsprobleme auf Buckets, die Punkte im Namen haben, mit den Versionen in Debian Jessie jedoch sehr wohl. Better safe than sorry … ) Außerdem kann die geographische Region ausgewählt werden, in der der “Bucket” angelegt werden soll. Neben Irland ist hier nun auch Frankfurt als Standort auswählbar; für den Zugriff dort wird aber nur die Protokollversion 4 unterstützt, was wiederum zu Schwierigkeiten führen kann. Ich empfehle daher eu-west-1 (Irland) als Region.

Jetzt brauchen wir noch einen Benutzer, der auf den Bucket zugreifen kann. Ein solcher lässt sich in der IAM Console anlegen. Die dabei erzeugte Access-Key-ID und der zugehörige Secret Key müssen unbedingt heruntergeladen und sicher aufbewahrt werden.

Danach bekommt der neu erzeugte Benutzer noch eine Policy mit den nötigen Zugriffsrechten verpasst. Dazu wählen wir ihn in der Benutzerliste aus, wählen den Tab Permissions an und klicken unter Inline Policies auf Create User Policy. Diese Policy sollte dann wie folgt aussehen:

{
    "Statement": [
        {
            "Action": [
                "s3:ListAllMyBuckets"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Action": "s3:*",
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::accountname-backup-servername",
                "arn:aws:s3:::accountname-backup-servername/*"
            ]
        }
    ]
}

Statt accountname-backup-servername ist der Name des vorher neu angelegten S3-Buckets zu verwenden. Dieser Benutzer darf sich also eine Liste aller “Buckets” anzeigen lassen und auf den genannten “Bucket” und alle Dateien darin zugreifen.

duply-Konfiguration

Update: Die Beschreibung der Konfiguration gilt für Debian 8.0 Jessie und Debian 9.0 Stretch.

In der duply-Konfiguration (Datei conf) treffen wir jetzt noch folgende Einstellungen:

TARGET='s3://s3-eu-west-1.amazonaws.com/accountname-backup-servername'
TARGET_USER='AccessKeyID'
TARGET_PASS='SecretAccessKey'

Update: Ab Debian Stretch muss es statt TARGET_USER und TARGET_PASS wie folgt heißen:

export AWS_ACCESS_KEY_ID='AccessKeyID'
export AWS_SECRET_ACCESS_KEY='SecretAccessKey'

Für s3-eu-west-1 (Region Irland), accountname-backup-servername, AccessKeyID und SecretAccessKey sind jeweils die passenden Werte zu verwenden; AccessKeyID und SecretAccessKey wurden bei der Einrichtung des IAM-Benutzers erzeugt.

Außerdem müssen duplicity noch einige zusätzliche Parameter übergeben werden:

DUPL_PARAMS="$DUPL_PARAMS --s3-use-new-style --s3-european-buckets --s3-use-multiprocessing "

Update: Ab Debian Stretch benötigt auch gpg zusätzliche Parameter:

GPG_OPTS='--pinentry-mode loopback'

Jetzt kann der erste Backuplauf mit duply NAME backup gestartet werden. Nach dem Abschluss des Backup-Laufs finden sich im “Bucket” in der S3 Console die gesicherten Dateien.

Fertig!

nanoc: Auswahl des Templates via YAML

nospam@example.com (Thomas Hochstein) — Wed, 29 Apr 2015 05:26:00 +0000

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

Kennzeichnung von Links in HTML-Dokumenten

nospam@example.com (Thomas Hochstein) — Thu, 08 Jan 2015 19:30:00 +0000

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="https://netz-rettung-recht.de/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.

Kennzeichnung mit Grafiken durch CSS-Klassen

Deutlich eleganter funktioniert es, wenn man den entsprechenden Links stattdessen eine spezielle CSS-Klasse zuweist und die passende Grafik auf diese Weise (als Hintergrundgrafik) einblendet, bspw. so:

a.mailto {
  color          : #00f;
  text-decoration: none;
  margin-left    : 3px;
  padding-left   : 20px;
  background     : url(envelope.gif) no-repeat left;
}

Ein Link der Form <a class="mailto" href="mailto:thh@inter.net">thh@inter.net</a> wird auf diese Weise in blauer Schriftfarne und ohne Unterstreichung dargestellt; außerdem wird links von dem Linktext das Symbol eines Briefumschlags eingeblendet. Das ist schon ganz schick, erfordert aber jeweils die Zuweisung einer passenden Klasse für jeden einzelnen Link - also wiederum Schreibaufwand. Und was ist mit automatisch generierten HTML-Seiten, bspw. solchen, die aus Markdown heraus erzeugt werden, oder in denen aus anderen Gründen diesen Links nicht die richtige Klasse zugewiesen ist?

Kennzeichnung mit Grafiken durch CSS-Attributselektoren

Auch dafür gibt es eine Lösung. Mit CSS 3.0 lässt sich das Prinzip nämlich noch schöner (und einfacher) umsetzen, und zwar mit sog. Attributselektoren.

Damit kann die Anwendung einer CSS-Definition auf Elemente beschränkt werden, deren Attribute einen bestimmten Wert enthalten oder, ab CSS 3.0, mit einem bestimmten Wert beginnen. Und unsere vorstehende Definition soll ja gerade nur auf Links (also <a>-Elemente) angewandt werden, deren Attribut href mit dem Wert mailto: beginnt. Voilà:

a[href^="mailto:"] {
  color          : #00f;
  text-decoration: none;
  margin-left    : 3px;
  padding-left   : 20px;
  background     : url(envelope.gif) no-repeat left;
}

Diese Definition sorgt dafür, dass jeder Link der Form <a href="mailto:thh@inter.net">thh@inter.net</a> ohne weitere Zuweisung einer CSS-Klasse automatisch wie im vorigen Beispiel formatiert wird, einschließlich der links davon eingeblendeten Grafik mit dem Briefumschlag.

CSS-Attributselektoren und Icons

Statt der Verwendung einer Grafik kann man jetzt noch einen Schritt weiter gehen und Symbole oder Icons aus einem Iconfont wie GLYPHICONS oder Font Awesome zusammen mit dem CSS-Pseudoelement :before verwenden, die dann auch von der Größe her an den Text angepasst sind.

Dazu müssen zunächst die Schriftart an sich und die entsprechenden CSS-Definitionen (heruntergeladen und) eingebunden werden. In der einfachsten Fassung genügt aber zunächst im <head>-Segment der Webseite die Zeile:

<link rel="stylesheet" href="//maxcdn.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.min.css">

Die CSS-Definition könnte dann wie folgt aussehen:

a[href^="mailto:"]:before {
  /* Unicode-Wert f0e0 fuer "envelope" 
     http://fontawesome.io/icon/envelope/ */
  content: "\f0e0";
  position: relative;
  top: 2px;
  display: inline-block;
  padding-left: 3px;
  padding-right: 4px;
  line-height: 1;
  font-family: 'FontAwesome';
  font-style: normal;
  font-weight: normal;
  font-size: 90%;
}

Ein zusätzliches

a[href^="mailto:"] {
  text-decoration: none;
}

unterbindet dann noch die Unterstreichung des Links.

Auf dieselbe Weise kann jedes beliebige Icon vor (oder hinter) ein Element gesetzt werden; notwendig ist nur die Angabe der richtigen font-family und des Unicode-Wertes des jeweiligen Zeichens, eingeleitet mit dem Backslash \, als content-Wert.

Andere Arten von Links kennzeichnen

In gleicher Weise lassen sich bspw. externe Links, also solche, die auf Ressourcen außerhalb der eigenen Website zeigen, oder Links, die sich in einem neuen Fenster oder Tab öffnen sollen, kennzeichnen. Ebenso können Links mit anderen Protokollen gekennzeichnet werden.

Die passenden Attributselektoren würden lauten

a[href^="http"]:before für externe Links, die mit http oder https beginnen,
a[href^="ftp"]:before für das Protokoll FTP oder auch
a[target^="_blank"]:before für Links, die sich in einem neuen Fenster oder Tab öffnen sollen.

Der Phantasie sind insoweit keine Grenzen gesetzt.

Ausgabe der Symbole unterdrücken

Soll ein Link einmal ausnahmsweise nicht gekennzeichnet werden, weil er sich bspw. in einem Navigationselement befindet, kann eine CSS-Klasse wie

.no-symbols a:before  {
  content: none;
}

definiert werden, die dann dem umgebenden Element des Links zugewiesen wird, also bspw. so:

<p class="no-symbols"><a href="mailto:thh@inter.net">thh@inter.net</a></p>

So lassen sich also mit diesen einfachen Definitionen Links quasi “magisch” mit passenden Symbolen versehen - oder eben auch gerade nicht, je nachdem, wie der Kontext es erfordert.

[Dieser Eintrag wurde nachträglich im Februar 2015 veröffentlicht.]

Kommentare des Blogautors hervorheben

nospam@example.com (Thomas Hochstein) — Sun, 01 Jun 2014 07:45:00 +0000

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:

.serendipity_comment_author_self {
background: #ff9;
padding: 0.5em;
border-radius: 0.75em;
}

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:

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

Dokuwiki als "Multisite"-Installation

nospam@example.com (Thomas Hochstein) — Fri, 30 May 2014 10:55:00 +0000

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. Die Vorgehensweise zur Einrichtung ist recht einfach:

Man legt das “Master”- (oder “Farm”-) Wiki ganz normal an. Dieses Wiki kann man entweder als eigenständige Wiki-Instanz benutzen, oder man nutzt es nur zur Installation der Plugins und Templates, die den einzelnen “nachrangigen” Wiki-Installationen (“Slaves”, “Animals”) zur Verfügung stehen sollen. Auch das “Master”-Wiki muss aufrufbar sein, zumindest lokal.
Dieses Wiki konfiguriert man hinreichend sicher und installiert dort alle Plugins und Templates, die in irgendeinem der “nachrangigen” Wikis benötigt werden, denn nur diese stehen dort zur Verfügung. Die Installation eigener Plugins und Templates ist nicht möglich.
Man legt ein “Multisite-Stammverzeichnis” an, unter dem für jedes “nachrangige” Wiki ein eigenes Unterverzeichnis angelegt wird. Dieses Verzeichnis muss dem Hostnamen in der URL des Wikis (der “Domain”) entsprechen, also bspw. “wiki.domain.example” oder “blablubb.schwupp.example” heißen. Will man ein Wiki unter mehreren Namen aufrufen können, wird das nur als Redirect auf einen “Hauptnamen” (oder mittels Rewrite auf Ebene des Webservers) möglich sein.
Man aktiviert den “Multisite”-Modus im “Master”-Wiki.
Für jedes “nachrangige” Wiki wird das entsprechend benannte Unterverzeichnis im “Stammverzeichnis” angelegt und ein Template einkopiert.
In der Webserver-Konfiguration legt man den vhost so an, dass dessen DocumentRoot auf das Verzeichnis des “Master”-Wikis (!) zeigt (nicht auf das Verzeichnis des “nachrangigen” Wikis). Die DocumentRoot-Einträge sind also für jedes “nachrangige” Wiki identisch!
Webserver neustarten, URL des nachrangigen Wikis aufrufen, mit Standardpasswort einloggen, dieses ändern und das Wiki konfigurieren. Ungewollte Plugins kann man dort deaktivieren.
Weitere Wikis legt man durch Wiederholung der Schritte 5-7 an. Das Template für die neuen Wikis kann man nach den eigenen Bedürfnissen modifizieren; auch ist es durch entsprechende Konfiguration möglich, bspw. Benutzerdaten pp. zwischen mehreren Wiki-Instanzen zu teilen.
Updates - von DokuWiki wie von Plugins und Templates - erfolgen immer nur im “Master”-Wiki.

Die entsprechende Dokumentation findet sich im DokuWiki-Wiki unter DokuWiki Farms; dort sind auch weitere Hinweise - u.a. zur Möglichkeit einer Konfiguration via .htaccess und andere, ältere Lösungsmöglichkeiten - zu finden. Meines Wissens stellt Debian in aktuellen Versionen in seinem DokuWiki-Paket auch entsprechende Tools zum “automatischen” Anlegen und Löschen von “Multisite”-Wikis über die Kommandozeile zur Verfügung.

Hinweis:
Eine (un-)regelmäßig aktualisierte Anleitung zu diesem Thema findet sich in meinem Wiki unter “Multisite”-Installation von DokuWiki.

Netz - Rettung - Recht (Artikel mit Tag anleitung)

irc.szaf.org

Installation und Erstkonfiguration

TLS

Vernetzung mit anderen IRC-Servern

"Sprechende" Message-IDs erzeugen mit dem INN

Message-IDs, ihr Aufbau und ihre Funktion

Funktion

Aufbau einer Messsage-ID

Beispiele für Message-IDs

Vorteile einer selbst erzeugten Message-ID

“Sprechende” Message-IDs

“Sprechende” Message-IDs mit dem INN erzeugen

Blogbeiträge in sozialen Medien teilen

Blogbeiträge in sozialen Medien teilen

Vorschaubilder für Links bei Twitter und Facebook (und anderswo)

serendipity_event_social

serendipity_event_metadesc

Sharebuttons mit serendipity_event_social

Beiträge automatisch teilen

serendipity_event_twitter

Zusammenfassung

Zusammenfassende Linkliste

Grundlagen

Share-Buttons

Automatisierungsdienste

Serendipity-Plugins

Ein Serendipity-Testblog auf dem aktuellen Stand halten

Logfile-Auswertung mit AWStats

Ein Logfile pro virtual host

Eine AWStats-Konfigurationsdatei pro virtual host

Statistik erstellen und im Web mit AWStats anschauen

Regelmäßige Aktualisierung der Statistik per Cronjob

Rotation der zusätzlich für AWStats angelagen Logfiles

letsencrypt jenseits des Webservers

Erhalt des Zertifikats

Installation des Zertifikats

Dovecot

Exim

INN

Zertifikat-Updates

Exim

INN

Und ihr?

Open Graph Protocol und Twitter Cards

Open Graph Protocol

Definition und ein Beispiel

Probieren geht über Studieren

Hinweise und Tipps für die eigene Anwendung

Twitter Cards

Definition und ein Beispiel

Probieren geht über Studieren

Hinweise und Tipps

Weiterer Lesestoff

Open Graph und Facebook

Twitter Cards

PHP-FPM - jetzt mit mod_proxy_fcgi

PHP-FPM und mod_proxy_fcgi installieren

mod_proxy_fcgi für PHP-FPM konfigurieren

Pools für einzelne Benutzer einrichten

Die Installation testen

SSL/TLS mit Let's Encrypt

Let’s Encrypt - die Prinzipien

Let’s Encrypt und der Apache-Webserver unter Debian Jessie

Installation

Zertifikat erstellen lassen

Zertifikat beim Apache einbinden

Zertifikate erneuern

Weiterer Lesestoff

Der eigene Webserver mit SSL/TLS

SSL-/TLS-Zertifikate und deren Prüfung

HTTPS im Speziellen

Virtual Hosting

Lösungswege

Die eigene CA

SAN

SNI

Kommerzielle Zertifikate

Die Zukunft: letsencrypt

SSL-Zertifikate und Apache

`serendipity_event_social`

`serendipity_event_metadesc`

Sharebuttons mit `serendipity_event_social`

`serendipity_event_twitter`

PHP-FPM und `mod_proxy_fcgi` installieren

`mod_proxy_fcgi` für PHP-FPM konfigurieren