ubuntuusers.de

22. Januar 2017

Mozilla hat in die Nightly-Version von Firefox eine Funktion integriert, um Webseiten-Fehler auf webcompat.com zu melden – einem globalen Bugtracker für das Web, den Mozilla ins Leben gerufen hat.

Bereits im April 2014 wurde die Initiative webcompat.com auf diesem Blog vorgestellt. Es handelt sich dabei um einen globalen Bugtracker, um Fehler auf beliebigen Webseiten zu melden. Ins Leben gerufen wurde das von der Community betreute Projekt von Mozilla. Dahinter steht das Ziel, dass Nutzer Webseiten fehlerfrei nutzen können – unabhängig davon, welchen Browser sie verwenden. Über die Plattform sollen Fehler gesammelt, untersucht und ggfs. Kontakt mit den Webseitenbetreibern aufgenommen werden.

Im November 2014 hat Mozilla eine einfache Möglichkeit in die Nightly-Version von Firefox für Android integriert, um Fehler auf Webseiten zu melden.

Mehr als zwei Jahre später integriert Mozilla auch in die Nightly-Version des Desktop-Browsers eine entsprechende Schaltfläche. Umgesetzt ist das Ganze als System-Add-on.

WebCompat Reporter

Klickt der Nutzer auf die Schaltfläche, öffnet sich das Formular zum Melden eines Fehlers in einem neuen Tab. Die Felder für die Seiten-URL, den Browser sowie das Betriebssystem werden automatisch ausgefüllt. Ebenfalls automatisch wird ein Screenshot von der aktuellen Ansicht erstellt und dem Ticket angehängt. Der Nutzer kann anschließend zusätzliche Informationen angeben und das Ticket dann wahlweise per GitHub-Konto oder anonym anlegen.

WebCompat Reporter

Die Integration ist ausschließlich in Nightly-Versionen von Firefox vorhanden. Wer keine Nightly-Version nutzt, kann auch die Erweiterung von Mozillas Add-on-Webseite installieren.

Der Beitrag Firefox Nightly erhält Fehler-Melden-Funktion für Webseiten erschien zuerst auf soeren-hentzschel.at.

21. Januar 2017

Der HTML-Standard sieht verschiedene Eingabe-Typen für verschiedene Aufgaben vor. So gibt es Eingabefelder für Texte, Zahlen, Passwörter, Farben und eben auch für das Datum und die Uhrzeit. Ab Firefox 53 unterstützt der Mozilla-Browser die Eingabe-Typen für Datum und Uhrzeit, so dass Webentwickler künftig auf keine JavaScript-Bibliothek mehr zurückgreifen müssen, um eine entsprechende Auswahl anzuzeigen.

Ein HTML-Code wie <input type=’text‘ /> kommt vermutlich allen Webentwicklern bekannt vor, denn diese einfachste Form eines Eingabefelds repräsentiert ein simples Textfeld und gehört zum Standard-Reportoire eines jeden Browsers, genau wie Passwort-Felder, Checkboxen, Radio-Buttons oder Upload-Felder für Dateien.

Daneben kamen mit HTML5 noch einige spezialisierte Eingabefelder dazu, wie für die Auswahl von Nummern, E-Mail-Adressen oder Farben. Bei den neuen Eingabe-Typen sieht es mit der browserübergreifenden Unterstützung nicht ganz so gut aus. Denn trotz grundlegender HTML5-Unterstützung in allen modernen Browsern hängt es bei Eingabefeldern vom jeweiligen Eingabe-Typ ab, ob ein Browser dieses unterstützt oder nicht. Unterstützt ein Browser einen Eingabe-Typ nicht, stellen alle Browser ohne Unterstützung dieses automatisch als simples Text-Eingabefeld dar.

Firefox 53 hat eine erste Unterstützung für <input type=’date‘ />und <input type=’time‘ /> erhalten, allerdings standardmäßig noch deaktiviert. Die Aktivierung erfolgt über about:config, indem die Schalter dom.forms.datetime respektive dom.forms.datetime.timepicker jeweils per Doppelklick auf true geschaltet werden.

Auswahlfelder für ein Datum oder eine Uhrzeit kennt man von vielen Webseiten. Diese werden bisher aber üblicherweise durch verschiedene JavaScript-Bibliotheken implementiert – und funktionieren dementsprechend auch nur, wenn der Nutzer JavaScript aktiviert hat. Durch die Verwendung von <input type=’date‘ /> und <input type=’time‘ /> können Browser nativ Auswahlfenster für das Datum oder die Uhrzeit implementieren, ohne dass eine JavaScript-Bibliothek hierfür eingesetzt werden muss. So steht diese Funktion allen Nutzern zur Verfügung, außerdem kann im Idealfall auch die Ladezeit der Webseite davon profitieren, wenn eine JavaScript-Bibliothek weniger geladen werden muss.

Darstellung von <input type=’date‘ /> in Firefox:

<input type='date' /> in Firefox

Darstellung von <input type=’time‘ /> in Firefox:

<input type='time' /> in Firefox

Der Beitrag Firefox 53: Unterstützung für Datums- und Uhrzeit-Wähler in HTML erschien zuerst auf soeren-hentzschel.at.

Angreifern von WordPress keine Chance geben

WordPress Seiten findet man immer häufiger im Internet. Das schlanke CMS ist sehr einfach zu bedienen und deshalb auch für Einsteiger interessant. Auch Firmen nutzen zum Start ins Internet sehr oft WordPress und tragen so zur rasanten Verbreitung bei. Die vielen Installationen von WordPress machen das Content-Management-System auch für Angreifer interessant. Die Bedienung von der Software ist so einfach, dass auch Web-Anfänger WordPress installieren und sich danach wenig um die Updates kümmern. Das öffnet Angreifern Tür und Tor.

Angreifer wollen euren Speicherplatz

Auch bei aktuell gehaltener Software und einer Minimalanzahl von Plugins gibt es genügend Schwachstellen, die man angreifen kann. Die größte Schwachstelle – und da kann WordPress selbst leider wenig machen – ist der Benutzer selbst. Durch zu leichte Passwörter lassen sich viel zu einfach Webseiten übernehmen.

Warum sollte jemand meine Webseite hacken?

In wenigen Ausnahmefällen interessiert sich der Angreifer tatsächlich für diese spezielle Webseite. Ein Wettbewerber könnte bei einer Firma gezielt Falschinformationen verbreiten, um sich selbst als besser da zu stellen. Das kommt vermutlich eher seltener vor.

In den allermeisten Fällen interessiert sich der Angreifer nicht für die eigentliche Webseite. In erster Linie geht es um die Übernahme des Servers bzw. zumindest des Speicherplatzes. Wer ins Backend von WordPress kommt, hat die Berechtigung, Dateien hochzuladen. Das ist ganz interessant, vor allem wenn es um urheberrechtlich geschütztes Material geht. Noch brisanter wird es, wenn es um illegale Daten geht, etwa gewaltverherrlichende Videos oder Kinderpornografie.

Als dritten Grund möchte ich Suchmaschinenoptimierung nennen. Wer von vielen Internetseiten Links auf seine Seite erhält, wird bei Google besser gerankt. Wer viele Zugangsdaten zu Webseiten hat, kann auch viele Links streuen und damit besser bei Google gefunden werden.

Wie kann ich Angreifer abhalten?

Es gibt sehr viele Sicherheits-Plugins für WordPress, die einem das Blaue vom Himmel versprechen. Zweifelsohne: Einige davon mögen hilfreich sein. Effektiver ist es aber, die Sicherheitsfunktion des Servers zu nutzen. Diese schützen auch vor so genannten Brute Force Attacken, bei denen Angreifer mit viel Rechenpower versuchen, die Passwörter zu erraten.

Sicherer Schutz der WordPress Anmeldeseite durch .htaccess

Mit der .htaccess-Datei kann man die Sicherheitsfunktion des Servers nutzen. Dabei ist das Prinzip so: Wenn man sich bei WordPress einloggen möchte, wird die Datei wp-login.php verwendet. Ohne diese Datei kann man sich nicht im Backend einloggen. Mit der .htaccess-Datei gibt man dem Server die Anweisung, dass nicht jeder auf diese Datei zugreifen darf. Wer diese Datei aufruft, muss seine Berechtigung dazu nachweisen – über einen Benutzernamen und Passwort.

.htaccess- und .htpasswd-Datei erstellen

Mit zwei einfachen Textdateien kann man den Serverschutz aktivieren.

  • .htaccess aktiviert das zugehörigen Servermodul und startet damit den Schutz der wp-login.php
  • .htpasswd enthält die Benutzernamen und (verschlüsselte) Passwörter, die den Zugang zu wp-login.php gewähren.

Schritt 1: Zunächst erstellt man die .htpasswd. Mit z.B. dem htpasswd-Generator kann man das Passwort verschlüsseln lassen und im Editor von Windows speichern. Mehrere Einträge sind möglich und sollten untereinander in die Datei geschrieben werden. Speichert die Datei unter dem Namen a.htpasswd auf dem Rechner ab.

htpasswd Datei Inhalt und WordPress schützen

Schritt 2: Jetzt erstellt man die .htaccess-Datei und füllt sie mit folgendem Inhalt. Speichert sie unter dem Namen a.htaccess auf dem PC ab.

# Stop Apache from serving .ht* files
<Files ~ "^.ht">
Order allow,deny
Deny from all
</Files>
&nbsp;
# Protect wp-login
<Files wp-login.php>
AuthUserFile /pfad/zur/.htpasswd
AuthName "Private access"
AuthType Basic
</Files>

Die Zeile die mit AuthUserFile anfängt, muss natürlich angepasst werden. Wenn ihr nicht wisst, wie der genaue Pfad dorthin lautet, erstellt fix eine PHP-Datei (zum Beispiel „pfad.php“) mit folgendem Inhalt, ladet sie mit FTP hoch und ruft sie im Browser auf (www.example.com/pfad.php). Löscht die Datei danach gleich wieder!

<html> 
<head> 
<title>absoluter-pfad</title> 
</head> 
&nbsp;
<body> 
<?php 
&nbsp;echo $_SERVER['DOCUMENT_ROOT']; 
?> 
</body> 
</html>

Schritt 3: Beide Dateien, a.htaccess und a.htpasswd werden mit FTP im WordPress-Hauptverzeichnis abgelegt.

Mit FTP die htaccess-Datei in das WordPress Hauptverzeichnis ablegen

Schritt 4: Benennt beide Dateien auf dem Server um, indem ihr das a vor dem Punkt entfernt. Die Dateien heißen jetzt .htaccess und .htpasswd und entfalten ihre Funktionen.

Hinweis: Falls dort schon .htaccess ist, öffnet die alte Datei und fügt den neuen Inhalt unten drunter hinzu!

Wie schützt mich die .htaccess-Datei vor Angreifern?

Professionelle Angreifer sitzen nicht mehr selbst am PC und versuchen die Passwörter zu knacken. Stattdessen nutzen sie Bot-Netzwerke und greifen automatisiert WordPress-Seiten an. Die Bots suchen gezielt nach einfachen Systemen und nutzen Schwachstellen von WordPress. Wenn dieser Bot nun auf das zusätzliche Sicherheitssystem stößt, bricht er entweder ab, oder er bricht sich die Zähne aus.

Was kann ich für meine Sicherheit tun?

Das wichtigste ist natürlich, die Software aktuell zu halten. Die Entwickler von WordPress bringen immer mal wieder Updates für die Software heraus, die man stets installieren sollte. In den meisten Fällen geht es dabei um Sicherheitsupdates.

Weiterhin sehr wichtig sind sichere Passwörter. Noch ist diese Botschaft nicht bei jedem angekommen, denn viel zu viele Leute verwenden viel zu einfache oder zu kurze Passwörter.

The post WordPress Sicherheit erhöhen mit .htaccess – so geht’s in 4 Schritten! first appeared on bejonet.

20. Januar 2017

Das select-Feld des HTML-Standards erlaubt die Auswahl einer Option aus einer Liste. Je mehr Optionen diese Liste beinhaltet, desto schwieriger kann es sein, den gewünschten Eintrag zu finden. Eine Neuerung von Firefox 53 hilft in solchen Situationen.

Standardmäßig kennt das <select>-Feld des HTML-Standards keine Suchfunktion, so dass Anwender auf Webseiten mit langen Auswahllisten unter Umständen lange den gesuchten Eintrag suchen müssen. Firefox-Nutzer haben es ab Firefox 53 einfacher: dann nämlich zeigt Firefox bei <select>-Feldern mit mehr als 40 Optionen ein Suchfeld an. Dieses filtert die Liste noch während der Eingabe, so dass der Nutzer schneller zum Ziel kommt.

<select>-Suchfeld Firefox 53

Die Neuerung ist bereits Bestandteil der Nightly-Version von Firefox 53, allerdings noch standardmäßig deaktiviert. Aktiviert kann die Neuerung werden, indem über about:config der Schalter dom.forms.selectSearch per Doppelklick auf true geschaltet wird. Die standardmäßige Aktivierung dieses Features kann in diesem Ticket verfolgt werden.

Der Beitrag Firefox 53: Suchfeld in select-Feldern bei vielen Optionen erschien zuerst auf soeren-hentzschel.at.

Mozilla, bekannt durch den Webbrowser Firefox, den E-Mail-Client Thunderbird oder das Bugtracking-Tool Bugzilla, gab vorgestern die Umstellung auf ein neues Logo-Design bekannt. Besonders an diesem Redesign ist die Einbindung der Community von Anfang an.

Der neue Schriftzug „moz://a“ hebt die Verbindung zur Web hervor und wird durch das aus den URLs bekannte :// charakterisiert. Parallel wurde mit „Zilla“ für das Logo eine neue Schriftart entwickelt, die Mozilla in den nächsten Wochen ebenfalls unter einer Open Source-Lizenz veröffentlicht.

Weitere Informationen sind in der Ankündigung sowie im Blog von Sören Hentzschel zu finden.

19. Januar 2017

Mozilla hat heute seinen ersten „Statusbericht zur Internetgesundheit“ veröffentlicht. In diesem setzt sich Mozilla auf Grundlage von Forschungsergebnissen mit den Dingen auseinander, welche dem Internet helfen respektive ihm schaden.

Mozilla beschreibt seinen Statusbericht zur Internetgesundheit als „Open-Source-Initiative, die mithilfe von Forschungsergebnissen aus verschiedenen Quellen den Zustand des Internets dokumentiert und erklärt“. Konkret befasst sich Mozilla dabei mit fünf Themenkomplexen:

1. Offene Innovation – ist Innovation offen?
2. Digitale Inklusion – wer ist im Internet willkommen?
3. Dezentralisierung – wer kontrolliert das Internet?
4. Datenschutz und Sicherheit – ist es geschützt und sicher?
5. Digitale Bildung – wer kann online erfolgreich sein?

Alle diese Themenkomplexe sind jeweils unterteilt in die Abschnitte „Überblick“, „Gesund“, „Ungesund“ sowie „Prognose“. Außerdem sind die Themenkomplexe mit empfohlenen Artikeln zum jeweiligen Thema verknüpft.

Der Bericht ist in verschiedenen Sprachen verfügbar, darunter auch Deutsch. Die Leser des Berichts sind ausdrücklich aufgefordert, sich ihre eigenen Gedanken zu machen und diese mitzuteilen, um so zur Verbesserung des nächstes Statusberichts beizutragen.

Mehr Informationen gibt es in der offiziellen Presseankündigung zum Thema.

Der Beitrag Mozilla veröffentlicht Statusbericht zur Internetgesundheit erschien zuerst auf soeren-hentzschel.at.

Unter dem Namen IT Landscape for sysadmins ist eine kleine aber feine Übersicht diverser OpenSource Projekte zu finden.

Unterteilt in Kategorien wie Protokolle, Cloud & Virtualisierung, Storage, Monitoring, Support Systeme, Messaging, Automation oder Essentials finden sich viele bekannte FOSS (Free and Open Source Software) Tools.

IT-Landscape-for-sysadminsSolche Landschaftsgrafiken sind ja vom Marketing, Social Media oder IT Dienstleistern durchaus bekannt, bisher ist mir aber keine Übersicht für OpenSource Software untergekommen.
Umso besser, dass Alen Krmelj Mitte 2015 das Projekt Sysadmin Open Source Landscape ins Leben gerufen hat.

IT-LandscapeDie Sammlung kann sich jetzt schon sehen lassen und darf dank ihrer offenen Architektur von allen erweitert werden. Dazu genügt ein Klick auf das Plus Symbol in der jeweiligen Kategorie.

Wer sich die IT-Landschaft ausdrucken möchte, der kann dank der verschienden Ansichten (oben rechts) eine einfach Liste abspeichern. 

Fazit

Tolles Projekt, welches bei der Suche nach Lösungen in einem bestimmten Bereich sicherlich eine gute Hilfestellung im Hinblick auf eine große Auswahl an Software bietet. Gerade für Systemadministratoren oder andere Berufe im IT Wesen bietet diese Grafik einen Mehrwert.

IT Landscape

Nach dem ich euch im ersten Teil erklärt habe, wie ihr eine Hugo-Website mit einem vorgefertigten Theme erstellen könnt, lernt ihr hier, ein eigenes Theme zu erstellen. Grundkenntnisse in HTML sind dafür selbstverständlich Voraussetzung. Auch Erfahrung in Go kann nicht schaden - ist für diesen Beitrag aber nicht erforderlich. Hier soll es um die Erstellung eines sehr grundlegenden Themes gehen. Ich werde daher nur auf die wichtigsten Aspekte eingehen und das Thema “Design” beispielsweise ganz beiseite lassen. Dieses Theme könnt ihr nach Belieben erweitern und ändern. Ich will euch nur eine Grundlage an die Hand geben.

Die Go Templatesprache

Während die Dokumentstruktur durch HTML vorgegeben wird, wird der Programmfluss innerhalb des Themes durch Elemente aus der Go-Templatesprache gesteuert. Die Template-Elemente werden durch zwei geschweifte Klammern vom übrigen HTML-Code abgegrenzt, z.B. so:

<h1> {{ .Title }} </h1>
<div class="content">
{{ .Content }}
</div>

In diesem Beispiel werden Titel und Inhalt einer Seite an der jeweiligen Stelle im Code ausgegeben. Der fertig generierte HTML-Code für eine Seite könnte dann z.B. so aussehen:

<h1> Mein erster Hugo-Beitrag </h1>
<div class="content">
Das ist mein erster Beitrag im neuen Hugo-basierten Blog.
</div>

Neben einfachen Ausgaben sind auch Programmfluss steuernde Elemente wie Bedingungen und Schleifen möglich. Eine Übersicht über alle Funktionselemente erhaltet ihr in der Hugo Dokumentation unter https://gohugo.io/templates/functions/ . Eine Übersicht aller standardmäßig verfügbaren Variablen (wie z.B. “Title”, oder “Content”) findet ihr hier: https://gohugo.io/templates/variables/

Aufbau des Beispiel-Themes

Navigiert in euer Projektverzeichnis für eure neue Website, die ihr zuvor via

hugo new site ./

erstellt habt. Führt dort das Kommando zum Erstellen eines neuen Theme-Grundgerüsts aus:

hugo new theme meintheme

Im themes/ Verzeichnis findet ihr jetzt ein neues Verzeichnis “meintheme”. Ändert die Hauptkonfiguration in config.toml so, dass euer neues Theme verwendet wird:

theme = "meintheme"

Wenn ihr jetzt den integrierten Webserver via hugo serve startet und die Seite im Browser (http://localhost:1313) ladet, solltet ihr nur eine weiße Seite sehen. Wir werden das neue Theme jetzt Stück für Stück aufbauen und fangen mit dem Header an.

Der Header

Der Header enthält alle Seitenelemente, die für jede Einzelseite strukturell gleich sind. Also <html>, <head> bis hin zum <body> Tag. Ein fertiger Header kann beispielsweise so aussehen:

<!doctype html>
<html>
<head>
<title> {{ if .IsHome }} {{ .Site.Title }} {{ else }} {{ .Title }} {{ end }} </title>
<meta charset="utf-8">
</head>
<body>

Übernehmt den Inhalt im Theme-Verzeichnis unter themes/meintheme/layouts/partials/header.html. Im “partials” Verzeichnis werden kleine Code-Snippets gesammelt, welche später durch {{ partial ... }}-Anweisungen in andere Template-Dateien geladen werden können. Das Template kann man auf diese Weise sehr gut strukturieren und einzelne Elemente wiederverwenden.

Der Footer

Das dazu passende Gegenstück zum Header-Partial bildet der Footer in themes/meintheme/layouts/partials/footer.html:

 </body>
</html>

Header und Footer in die Übersichtsseite laden

Die Code-Schnipsel für Header und Footer sind erstellt und können jetzt in beliebige, andere Template-Dateien geladen werden. Für das Blog-Theme soll es zwei Seiten-Typen geben: Übersichtsseiten und Einzelseiten. Übersichtsseiten werden in themes/meintheme/layouts/_default/list.html definiert, Einzelseiten in themes/meintheme/layouts/_default/single.html. Lasst uns mit der Übersichtsseite anfangen, sodass wir erste Inhalte auf der Startseite ausgeben können:

list.html:

<!-- Header -->
{{ partial "header.html" . }}
<!-- Content -->
<!-- Footer -->
{{ partial "footer.html" . }}

Löscht jetzt die Datei “themes/meintheme/layouts/index.html”. Sie sorgt für eine gesonderte Darstellung der Startseite. Da wir hier aber eine Übersicht laden wollen, und keine speziell angepasste Seite, muss sie entfernt werden, um das gewünschte Ergebnis zu erhalten. Aktuell ist die Seite noch sehr leer: Außer dem Seitentitel in der Titelzeile des Browser-Tabs ist noch nichts zu sehen.

Inhalte für die Übersichtsseite

Um die Website mit etwas Inhalt zu füllen, kümmern wir uns im nächsten Schritt um die Übersichtsseite. Hier sollen Ausschnitte aus den letzten Blogposts angezeigt werden. Inhalt der themes/meintheme/layouts/_default/list.html:

<!-- Header -->
{{ partial "header.html" . }}
<!-- Loop through all posts -->
{{ range .Pages }}
<h2>{{ .Title }}</h2>
<p>
<small>{{ .Date.Format "02.01.2006" }}</small>
</p>
{{ .Summary }}
<p>
<a class="readmore" href="{{ .RelPermalink }}">Weiterlesen</a>
</p>
{{ end }}
<!-- End loop -->
<!-- Footer -->
{{ partial "footer.html" . }}

Jetzt ist es Zeit für einen ersten Test: Startet den Hugo Webserver via hugo -D serve und seht euch die Seite im Webbrowser an. Alle existierenden Posts sollten nun untereinander in Ausschnitten aufgelistet sein.

Um überhaupt etwas zu sehen, muss an dieser Stelle schon mindestens ein Blogpost erstellt worden sein!

Einzelseiten definieren

Die “Weiterlesen”-Links auf der Übersichtsseite führen noch ins leere. Darum kümmern wir uns jetzt. Es soll zwei Typen von Einzelseiten geben: Beitragsseiten für Blogeinträge (“articles”) und normale Seiten z.B. für Impressum, Kontakt etc. (“pages”). Durch diese Unterscheidung kann man die verschiedenen Inhaltetypen unterschiedlich gestalten. Bei normalen Seiten kann man z.B. das Datum und ggf. später Kommentare ausblenden lassen, während man bei Beitragsseiten nach dem Seiteninhalt noch “Share”-Buttons einblendet. Hugo unterscheidet standardmäßig nicht zwischen diesen beiden Seitentypen. Das macht aber nichts - wir können die Unterscheidung selbst nachbilden. Dazu wird ein neues Seitenattribut “Type” eingeführt, welches definiert, ob ein Inhalt vom Typ “article” oder “page” ist. Das Attribut wird in den Kopf jeder Markdown-Inhaltsseite aufgenommen, z.B. so:

+++
date = "2017-01-17T09:28:11+01:00"
title = "Hallo Welt!"
draft = true
type = "article"
+++

Nun aber zur Template-Programmierung. Für Einzelseiten wird immer die Datei themes/meintheme/layouts/_default/single.html geladen. Innerhalb dieser Datei soll eine Überprüfung stattfinden, um welchen Seitentyp es sich handelt, um dann das jeweils passende “Partial” - also ein Sub-Template - zu laden. Der Inhalt der single.html soll wie folgt aussehen:

<!-- Header -->
{{ partial "header.html" . }}
{{ if eq .Type "page" }}
{{ partial "page.html" . }}
{{ else }}
{{ partial "article.html" . }}
{{ end }}
<!-- Footer -->
{{ partial "footer.html" . }}

Die beiden Partials “page.html” und “article.html” müssen in themes/meintheme/layouts/partials/ noch definiert werden:

article.html

<h1>{{ .Title }}</h1>
<p>
<small>{{ .Date.Format "02.01.2006" }}</small>
</p>
{{ .Content }}
<!-- Tags -->
{{ if isset .Params "tags" }}
{{ $baseURL := .Site.BaseURL }}
<ul class="tags">
{{ range .Params.tags }}
<li> <a href="{{ $baseURL }}tags/{{ . | urlize }}/">#{{ . }}</a> </li>
{{ end }}
</ul>
{{ end }}

page.html

<h1>{{ .Title }}</h1>
{{ .Content }}
Stellt sicher, dass jeder Blog-Beitrag mit type = "article" im Kopfbereich gekennzeichnet ist, sonst wird er nicht angezeigt!

Tags

Im unteren Teil der article.html befindet sich die Ausgabe der Tags, die einem Beitrag zugeordnet sind. Passende Tags können in der Kopfzeile jeder Markdown-Datei angegeben werden, z.B.

+++
date = "2017-01-17T09:28:11+01:00"
title = "Hallo Welt!"
draft = true
type = "article"
tags = [ "Begrüßung", "Allgemein" ]
+++

Wenn Tags vorhanden sind, werden sie unten auf der Seite eingeblendet. Ein Blick auf ein Tag führt zu einer Übersichtsseite mit dazu passenden Blogposts.

Normale Seiten ausblenden und Seitennavigation

Aktuell erscheinen auch normale Seiten (“pages”) wie z.B. eine Impressum-Seite in der Übersicht, wenn für sie type = "page" im Kopfbereich definiert wurde. Das können wir ändern, indem bei der Auflistung von Seitenausschnitten nur noch Inhalte vom Typ “article” berücksichtigt werden. Ändert dazu die list.html so ab:

<!-- Header -->
{{ partial "header.html" . }}
<!-- Loop through all posts -->
{{ $paginator := .Paginate (where .Data.Pages "Type" "article") }}
{{ range .Paginator.Pages }}
<h2>{{ .Title }}</h2>
<p>
<small>{{ .Date.Format "02.01.2006" }}</small>
</p>
{{ .Summary }}
<p>
<a class="readmore" href="{{ .RelPermalink }}">Weiterlesen</a>
</p>
{{ end }}
<!-- End loop -->
<!-- Navigation -->
{{ partial "page-navigation.html" . }}
<!-- Footer -->
{{ partial "footer.html" . }}

Ein “Paginator” filtert jetzt die Inhalte nach Typ und sorgt für die Einteilung in Seiten. Am unteren Ende der Seite wird via {{partial ... }} - ähnlich wie bei Header und Footer - ein kleines Snippet eingebunden, das die Navigation darstellt. Legt unter layouts/partials/ eine neue Datei “page-navigation.html” an, die folgendes enthält:

{{ if or (.Paginator.HasPrev) (.Paginator.HasNext) }}
{{ if .Paginator.HasNext }}
<a href="{{ .URL }}page/{{ .Paginator.Next.PageNumber }}">&larr; Ältere Beiträge&nbsp;&nbsp;&nbsp;&nbsp;</a>
{{ end }}
{{ if .Paginator.HasPrev }}
<a href="{{ .URL }}page/{{ .Paginator.Prev.PageNumber }}">Neuere Beiträge &rarr;</a>
{{ end }}
{{ end }}

In der Hauptkonfiguration config.toml kann mit Paginate eingestellt werden, nach wie vielen Beitrags-Ausschnitten eine neue Seite zum Blättern angelegt werden soll:

languageCode = "de-de"
title = "Meine Hugo-Site"
baseurl = "https://meinehugoseite.tld"
theme = "meintheme"
Paginate = 5

Stylesheet und RSS-Feed einbinden

Dem Header fehlen noch HTML-Tags zum Einbinden eines Stylesheets und des RSS-Feeds:

<!doctype html>
<html>
<head>
<title> {{ if .IsHome }} {{ .Site.Title }} {{ else }} {{ .Title }} {{ end }} </title>
<meta charset="utf-8">
<link rel="stylesheet" href="{{ .Site.BaseURL }}css/main.css">
{{ if .RSSLink }}<link href="{{ .RSSLink }}" rel="feed" type="application/rss+xml" title="{{ .Site.Title }}" />{{ end }}
</head>
<body>

Das Stylesheet kann im Theme-Ordner unter static/css/main.css angelegt werden. Der RSS-Feed wird automatisch generiert und kann unter http://localhost:1313/index.xml abgerufen werden. Standardmäßig enthält er jedoch - wie die Übersichtsseiten zuvor - auch einfache Seiten, die man nicht im Feed haben will. Wenn im RSS-Feed nur Inhalte vom Typ “article” erscheinen sollen, muss ein eigenes Template für den RSS-Feed erstellt werden:

themes/meintheme/layouts/rss.xml

<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>{{ with .Title }}{{.}} on {{ end }}{{ .Site.Title }}</title>
<link>{{ .Permalink }}</link>
<description>Die neuesten Inhalte auf {{ .Site.Title }}</description>
<generator>Hugo -- gohugo.io</generator>{{ with .Site.LanguageCode }}
<language>{{.}}</language>{{end}}{{ with .Site.Author.email }}
<managingEditor>{{.}}{{ with $.Site.Author.name }} ({{.}}){{end}}</managingEditor>{{end}}{{ with .Site.Author.email }}
<webMaster>{{.}}{{ with $.Site.Author.name }} ({{.}}){{end}}</webMaster>{{end}}{{ with .Site.Copyright }}
<copyright>{{.}}</copyright>{{end}}{{ if not .Date.IsZero }}
<lastBuildDate>{{ .Date.Format "Mon, 02 Jan 2006 15:04:05 -0700" | safeHTML }}</lastBuildDate>{{ end }}
<atom:link href="{{.URL}}" rel="self" type="application/rss+xml" />
{{ range first 15 .Data.Pages }}
{{ if eq .Type "article" }}
<item>
<title>{{ .Title }}</title>
<link>{{ .Permalink }}</link>
<pubDate>{{ .Date.Format "Mon, 02 Jan 2006 15:04:05 -0700" | safeHTML }}</pubDate>
{{ with .Site.Author.email }}<author>{{.}}{{ with $.Site.Author.name }} ({{.}}){{end}}</author>{{end}}
<guid>{{ .Permalink }}</guid>
<description>{{ .Content | html }}</description>
</item>
{{ end }}
{{ end }}
</channel>
</rss>

Über die Bedingung {{ if eq .Type "article" }} werden unpassende Inhalte ausgeblendet.


Das Grundgerüst eures Themes ist damit fertig! Jetzt braucht ihr noch passendenden HTML-Code und CSS-Regeln zu schreiben, um euer Design umzusetzen. Wenn ihr euer Theme noch erweitern und zusätzliche Funktionalität oder Inhalte hinzufügen wollt, empfehle ich euch, die Hugo Dokumentation zu lesen: https://gohugo.io/templates/overview/

Nach dem ich euch im ersten Teil erklärt habe, wie ihr eine Hugo-Website mit einem vorgefertigten Theme erstellen könnt, lernt ihr hier, ein eigenes Theme zu erstellen. Grundkenntnisse in HTML sind dafür selbstverständlich Voraussetzung. Auch Erfahrung in Go kann nicht schaden - ist für diesen Beitrag aber nicht erforderlich. Hier soll es um die Erstellung eines sehr grundlegenden Themes gehen. Ich werde daher nur auf die wichtigsten Aspekte eingehen und das Thema “Design” beispielsweise ganz beiseite lassen. Dieses Theme könnt ihr nach Belieben erweitern und ändern. Ich will euch nur eine Grundlage an die Hand geben.

Die Go Templatesprache

Während die Dokumentstruktur durch HTML vorgegeben wird, wird der Programmfluss innerhalb des Themes durch Elemente aus der Go-Templatesprache gesteuert. Die Template-Elemente werden durch zwei geschweifte Klammern vom übrigen HTML-Code abgegrenzt, z.B. so:

<h1> {{ .Title }} </h1>
<div class="content">
{{ .Content }}
</div>

In diesem Beispiel werden Titel und Inhalt einer Seite an der jeweiligen Stelle im Code ausgegeben. Der fertig generierte HTML-Code für eine Seite könnte dann z.B. so aussehen:

<h1> Mein erster Hugo-Beitrag </h1>
<div class="content">
Das ist mein erster Beitrag im neuen Hugo-basierten Blog.
</div>

Neben einfachen Ausgaben sind auch Programmfluss steuernde Elemente wie Bedingungen und Schleifen möglich. Eine Übersicht über alle Funktionselemente erhaltet ihr in der Hugo Dokumentation unter https://gohugo.io/templates/functions/ . Eine Übersicht aller standardmäßig verfügbaren Variablen (wie z.B. “Title”, oder “Content”) findet ihr hier: https://gohugo.io/templates/variables/

Aufbau des Beispiel-Themes

Navigiert in euer Projektverzeichnis für eure neue Website, die ihr zuvor via

hugo new site ./

erstellt habt. Führt dort das Kommando zum Erstellen eines neuen Theme-Grundgerüsts aus:

hugo new theme meintheme

Im themes/ Verzeichnis findet ihr jetzt ein neues Verzeichnis “meintheme”. Ändert die Hauptkonfiguration in config.toml so, dass euer neues Theme verwendet wird:

theme = "meintheme"

Wenn ihr jetzt den integrierten Webserver via hugo serve startet und die Seite im Browser (http://localhost:1313) ladet, solltet ihr nur eine weiße Seite sehen. Wir werden das neue Theme jetzt Stück für Stück aufbauen und fangen mit dem Header an.

Der Header

Der Header enthält alle Seitenelemente, die für jede Einzelseite strukturell gleich sind. Also <html>, <head> bis hin zum <body> Tag. Ein fertiger Header kann beispielsweise so aussehen:

<!doctype html>
<html>
<head>
<title> {{ if .IsHome }} {{ .Site.Title }} {{ else }} {{ .Title }} {{ end }} </title>
<meta charset="utf-8">
</head>
<body>

Übernehmt den Inhalt im Theme-Verzeichnis unter themes/meintheme/layouts/partials/header.html. Im “partials” Verzeichnis werden kleine Code-Snippets gesammelt, welche später durch {{ partial ... }}-Anweisungen in andere Template-Dateien geladen werden können. Das Template kann man auf diese Weise sehr gut strukturieren und einzelne Elemente wiederverwenden.

Der Footer

Das dazu passende Gegenstück zum Header-Partial bildet der Footer in themes/meintheme/layouts/partials/footer.html:

 </body>
</html>

Header und Footer in die Übersichtsseite laden

Die Code-Schnipsel für Header und Footer sind erstellt und können jetzt in beliebige, andere Template-Dateien geladen werden. Für das Blog-Theme soll es zwei Seiten-Typen geben: Übersichtsseiten und Einzelseiten. Übersichtsseiten werden in themes/meintheme/layouts/_default/list.html definiert, Einzelseiten in themes/meintheme/layouts/_default/single.html. Lasst uns mit der Übersichtsseite anfangen, sodass wir erste Inhalte auf der Startseite ausgeben können:

list.html:

<!-- Header -->
{{ partial "header.html" . }}
<!-- Content -->
<!-- Footer -->
{{ partial "footer.html" . }}

Löscht jetzt die Datei “themes/meintheme/layouts/index.html”. Sie sorgt für eine gesonderte Darstellung der Startseite. Da wir hier aber eine Übersicht laden wollen, und keine speziell angepasste Seite, muss sie entfernt werden, um das gewünschte Ergebnis zu erhalten. Aktuell ist die Seite noch sehr leer: Außer dem Seitentitel in der Titelzeile des Browser-Tabs ist noch nichts zu sehen.

Inhalte für die Übersichtsseite

Um die Website mit etwas Inhalt zu füllen, kümmern wir uns im nächsten Schritt um die Übersichtsseite. Hier sollen Ausschnitte aus den letzten Blogposts angezeigt werden. Inhalt der themes/meintheme/layouts/_default/list.html:

<!-- Header -->
{{ partial "header.html" . }}
<!-- Loop through all posts -->
{{ range .Pages }}
<h2>{{ .Title }}</h2>
<p>
<small>{{ .Date.Format "02.01.2006" }}</small>
</p>
{{ .Summary }}
<p>
<a class="readmore" href="{{ .RelPermalink }}">Weiterlesen</a>
</p>
{{ end }}
<!-- End loop -->
<!-- Footer -->
{{ partial "footer.html" . }}

Jetzt ist es Zeit für einen ersten Test: Startet den Hugo Webserver via hugo -D serve und seht euch die Seite im Webbrowser an. Alle existierenden Posts sollten nun untereinander in Ausschnitten aufgelistet sein.

Um überhaupt etwas zu sehen, muss an dieser Stelle schon mindestens ein Blogpost erstellt worden sein!

Einzelseiten definieren

Die “Weiterlesen”-Links auf der Übersichtsseite führen noch ins leere. Darum kümmern wir uns jetzt. Es soll zwei Typen von Einzelseiten geben: Beitragsseiten für Blogeinträge (“articles”) und normale Seiten z.B. für Impressum, Kontakt etc. (“pages”). Durch diese Unterscheidung kann man die verschiedenen Inhaltetypen unterschiedlich gestalten. Bei normalen Seiten kann man z.B. das Datum und ggf. später Kommentare ausblenden lassen, während man bei Beitragsseiten nach dem Seiteninhalt noch “Share”-Buttons einblendet. Hugo unterscheidet standardmäßig nicht zwischen diesen beiden Seitentypen. Das macht aber nichts - wir können die Unterscheidung selbst nachbilden. Dazu wird ein neues Seitenattribut “Type” eingeführt, welches definiert, ob ein Inhalt vom Typ “article” oder “page” ist. Das Attribut wird in den Kopf jeder Markdown-Inhaltsseite aufgenommen, z.B. so:

+++
date = "2017-01-17T09:28:11+01:00"
title = "Hallo Welt!"
draft = true
type = "article"
+++

Nun aber zur Template-Programmierung. Für Einzelseiten wird immer die Datei themes/meintheme/layouts/_default/single.html geladen. Innerhalb dieser Datei soll eine Überprüfung stattfinden, um welchen Seitentyp es sich handelt, um dann das jeweils passende “Partial” - also ein Sub-Template - zu laden. Der Inhalt der single.html soll wie folgt aussehen:

<!-- Header -->
{{ partial "header.html" . }}
{{ if eq .Type "page" }}
{{ partial "page.html" . }}
{{ else }}
{{ partial "article.html" . }}
{{ end }}
<!-- Footer -->
{{ partial "footer.html" . }}

Die beiden Partials “page.html” und “article.html” müssen in themes/meintheme/layouts/partials/ noch definiert werden:

article.html

<h1>{{ .Title }}</h1>
<p>
<small>{{ .Date.Format "02.01.2006" }}</small>
</p>
{{ .Content }}
<!-- Tags -->
{{ if isset .Params "tags" }}
{{ $baseURL := .Site.BaseURL }}
<ul class="tags">
{{ range .Params.tags }}
<li> <a href="{{ $baseURL }}tags/{{ . | urlize }}/">#{{ . }}</a> </li>
{{ end }}
</ul>
{{ end }}

page.html

<h1>{{ .Title }}</h1>
{{ .Content }}

Stellt sicher, dass jeder Blog-Beitrag mit type = "article" im Kopfbereich gekennzeichnet ist, sonst wird er nicht angezeigt!

Tags

Im unteren Teil der article.html befindet sich die Ausgabe der Tags, die einem Beitrag zugeordnet sind. Passende Tags können in der Kopfzeile jeder Markdown-Datei angegeben werden, z.B.

+++
date = "2017-01-17T09:28:11+01:00"
title = "Hallo Welt!"
draft = true
type = "article"
tags = [ "Begrüßung", "Allgemein" ]
+++

Wenn Tags vorhanden sind, werden sie unten auf der Seite eingeblendet. Ein Blick auf ein Tag führt zu einer Übersichtsseite mit dazu passenden Blogposts.

Normale Seiten ausblenden und Seitennavigation

Aktuell erscheinen auch normale Seiten (“pages”) wie z.B. eine Impressum-Seite in der Übersicht, wenn für sie type = "page" im Kopfbereich definiert wurde. Das können wir ändern, indem bei der Auflistung von Seitenausschnitten nur noch Inhalte vom Typ “article” berücksichtigt werden. Ändert dazu die list.html so ab:

<!-- Header -->
{{ partial "header.html" . }}
<!-- Loop through all posts -->
{{ $paginator := .Paginate (where .Data.Pages "Type" "article") }}
{{ range .Paginator.Pages }}
<h2>{{ .Title }}</h2>
<p>
<small>{{ .Date.Format "02.01.2006" }}</small>
</p>
{{ .Summary }}
<p>
<a class="readmore" href="{{ .RelPermalink }}">Weiterlesen</a>
</p>
{{ end }}
<!-- End loop -->
<!-- Navigation -->
{{ partial "page-navigation.html" . }}
<!-- Footer -->
{{ partial "footer.html" . }}

Ein “Paginator” filtert jetzt die Inhalte nach Typ und sorgt für die Einteilung in Seiten. Am unteren Ende der Seite wird via {{partial ... }} - ähnlich wie bei Header und Footer - ein kleines Snippet eingebunden, das die Navigation darstellt. Legt unter layouts/partials/ eine neue Datei “page-navigation.html” an, die folgendes enthält:

{{ if or (.Paginator.HasPrev) (.Paginator.HasNext) }}
{{ if .Paginator.HasNext }}
<a href="{{ .URL }}page/{{ .Paginator.Next.PageNumber }}">&larr; Ältere Beiträge&nbsp;&nbsp;&nbsp;&nbsp;</a>
{{ end }}
{{ if .Paginator.HasPrev }}
<a href="{{ .URL }}page/{{ .Paginator.Prev.PageNumber }}">Neuere Beiträge &rarr;</a>
{{ end }}
{{ end }}

In der Hauptkonfiguration config.toml kann mit Paginate eingestellt werden, nach wie vielen Beitrags-Ausschnitten eine neue Seite zum Blättern angelegt werden soll:

languageCode = "de-de"
title = "Meine Hugo-Site"
baseurl = "https://meinehugoseite.tld"
theme = "meintheme"
Paginate = 5

Stylesheet und RSS-Feed einbinden

Dem Header fehlen noch HTML-Tags zum Einbinden eines Stylesheets und des RSS-Feeds:

<!doctype html>
<html>
<head>
<title> {{ if .IsHome }} {{ .Site.Title }} {{ else }} {{ .Title }} {{ end }} </title>
<meta charset="utf-8">
<link rel="stylesheet" href="{{ .Site.BaseURL }}css/main.css">
{{ if .RSSLink }}<link href="{{ .RSSLink }}" rel="feed" type="application/rss+xml" title="{{ .Site.Title }}" />{{ end }}
</head>
<body>

Das Stylesheet kann im Theme-Ordner unter static/css/main.css angelegt werden. Der RSS-Feed wird automatisch generiert und kann unter http://localhost:1313/index.xml abgerufen werden. Standardmäßig enthält er jedoch - wie die Übersichtsseiten zuvor - auch einfache Seiten, die man nicht im Feed haben will. Wenn im RSS-Feed nur Inhalte vom Typ “article” erscheinen sollen, muss ein eigenes Template für den RSS-Feed erstellt werden:

themes/meintheme/layouts/rss.xml

<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>{{ with .Title }}{{.}} on {{ end }}{{ .Site.Title }}</title>
<link>{{ .Permalink }}</link>
<description>Die neuesten Inhalte auf {{ .Site.Title }}</description>
<generator>Hugo -- gohugo.io</generator>{{ with .Site.LanguageCode }}
<language>{{.}}</language>{{end}}{{ with .Site.Author.email }}
<managingEditor>{{.}}{{ with $.Site.Author.name }} ({{.}}){{end}}</managingEditor>{{end}}{{ with .Site.Author.email }}
<webMaster>{{.}}{{ with $.Site.Author.name }} ({{.}}){{end}}</webMaster>{{end}}{{ with .Site.Copyright }}
<copyright>{{.}}</copyright>{{end}}{{ if not .Date.IsZero }}
<lastBuildDate>{{ .Date.Format "Mon, 02 Jan 2006 15:04:05 -0700" | safeHTML }}</lastBuildDate>{{ end }}
<atom:link href="{{.URL}}" rel="self" type="application/rss+xml" />
{{ range first 15 .Data.Pages }}
{{ if eq .Type "article" }}
<item>
<title>{{ .Title }}</title>
<link>{{ .Permalink }}</link>
<pubDate>{{ .Date.Format "Mon, 02 Jan 2006 15:04:05 -0700" | safeHTML }}</pubDate>
{{ with .Site.Author.email }}<author>{{.}}{{ with $.Site.Author.name }} ({{.}}){{end}}</author>{{end}}
<guid>{{ .Permalink }}</guid>
<description>{{ .Content | html }}</description>
</item>
{{ end }}
{{ end }}
</channel>
</rss>

Über die Bedingung {{ if eq .Type "article" }} werden unpassende Inhalte ausgeblendet.


Das Grundgerüst eures Themes ist damit fertig! Jetzt braucht ihr noch passendenden HTML-Code und CSS-Regeln zu schreiben, um euer Design umzusetzen. Wenn ihr euer Theme noch erweitern und zusätzliche Funktionalität oder Inhalte hinzufügen wollt, empfehle ich euch, die Hugo Dokumentation zu lesen: https://gohugo.io/templates/overview/

18. Januar 2017

Mozilla hat heute seine neue visuelle Identität vorgestellt. Das neue Logo, in Anlehnung an ein Internet-Protokoll, repräsentiert ab sofort Mozilla.

Vor knapp sieben Monaten hat Mozilla einen ungewöhnlichen Prozess gestartet: statt bei der Suche nach einer neuen visuellen Identität eine Agentur mit der kompletten internen Ausarbeitung einer Idee bis hin zum fertigen Logo zu beauftragen, wurde die Community mit einbezogen, welche unterschiedliche Konzepte der Londoner Design-Agentur Johnson Banks beurteilte. Basierend auf dem Feedback der Community wurden die Ideen weiterentwickelt, bis Mozilla heute schließlich das finale Logo der Öffentlichkeit präsentiert hat.

Mozilla-Logo 2017

Das neue Logo zeigt Mozilla als Wortmarke mit einem Doppelpunkt gefolgt von zwei Schrägstrichen anstelle des „ill“ in Mozilla, in Anlehnung an bekannte Internet-Protokolle wie http:// oder https://.

Als verwendete Schriftart kommt Zilla zum Einsatz, eine von Mozilla in Auftrag gegebene Schriftart, erstellt von Typotheque in den Niederlanden. Die Schriftart ist – in typischer Mozilla-Manier – Open Source und wird frei verwendet werden können. Dies soll innerhalb des nächsten Monats soweit sein.

Zilla Font

Die neue Farbpalette, welche Mozilla repräsentiert, ist inspiriert von den Farben von Firefox sowie anderen Webbrowsern.

Mozilla-Logo Farbpalette

Dass es sich hierbei um mehr als nur ein Logo, sondern um eine vollständige visuelle Identität handelt, wird dadurch deutlich, dass es eine Design-Sprache gibt und unterschiedliche Variationen für unterschiedliche Projekte und Anlässe in einem einheitlichen Stil dargestellt werden können.

Mozilla-Logo Design-Sprache

Mozilla-Logo Design-Sprache

Mozilla wird die neue visuelle Identität phasenweise ausrollen. Ein Video wurde zusammengestellt und zeigt verschiedene Facetten der neuen Erscheinung.

Link zum Original-Video

Der Beitrag Mozilla hat ein neues Logo erschien zuerst auf soeren-hentzschel.at.

Spätestens seit 2013 gibt es Initiativen, die das XMPP-Netzwerk durch Transportverschlüsselung sicherer machen wollen. Mittlerweile unterstützen fast alle öffentlichen XMPP-Server zumindest optional Transportverschlüsselung via TLS oder SSL. Leider wird das Thema nur in den wenigsten Fällen wirklich ernst genommen - und das mache ich u.A. daran fest: In viel zu vielen Fällen können wir bei der Server-to-Server-Kommunikation folgendes finden:

  • Verwendung von selbst signierten Zertifikaten
  • Defekte / ungültige Zertifikatskonfigurationen (fehlendes Intermediate-Cert, abgelaufene Zertifikate, …)
  • Tolerierung unverschlüsselter Verbindungen

Vor allem gegen den letzten Punkt muss unbedingt etwas unternommen werden. Viel zu viele Server priorisieren zwar verschlüsselte Verbindungen, verifizieren angebotene Zertifikate jedoch nicht, und wenn kein Zertifikat angeboten wird, wird via Dialback authentifiziert oder die Verschlüsselung gleich ganz deaktiviert. Besser könnten die Konditionen für MitM-Attacken kaum sein. Man signalisiert damit zwar Bereitschaft, zu verschlüsseln, aber wenn er andere nicht will, oder wenn ein Angreifer auf der Leitung sitzt, dann verschlüsselt man eben nicht. Es leuchtet ein, dass das nicht besonders viel Sinn ergibt. Wenn wir Zertifikate nicht prüfen und bereit sind, die Verschlüsselung zu deaktivieren, damit jemand mit uns spricht, können wir es auch gleich sein lassen, und unverschlüsselt kommunizieren. Der Effekt ist derselbe: Wer mithören will, kann mithören.

Meiner Meinung nach ist es an der Zeit, “Ernst zu machen”, und seriöse Transportverschlüsselung einzuführen. Verpflichtend. Für alle. Ohne Ausnahmen - ohne wenn und aber.

Ich habe damit vor wenigen Tagen angefangen und meinen trashserver.net Dienst so konfiguriert, dass nur noch sichere, verschlüsselte Verbindungen von Servern akzeptiert werden, die ein gültiges TLS-Zertifikat von einer CA besitzen, welche allgemein anerkannt ist. D.h.: Keine Verbindungen mehr zu Servern, die keine oder ungültige Zertifikate besitzen, oder ein selbst signiertes Zertifikat nutzen.

Letztere schließe ich aus einem praktischen Grund aus: Der Aufwand, jedes individuelle Root-Zertifikat eines jeden Betreibers zu importieren und zu pflegen, der ein Self-Signed Zertifikat einsetzt, würde den Rahmen sprengen. Wir postulieren gerne eine XMPP-Welt, in der es möglichst viele Server gibt. Wir können aber nicht jedem kleinen Betreiber hinterherlaufen und sein Root-Zertifikat importieren, geschweige denn pflegen. Bei verpflichtender Verschlüsselung und Authentifizierung über das Zertifikat wäre ein neuer XMPP-Server so lange vom Rest des Netzes abgeschnitten, bis alle anderen Betreiber sein Root-Zertifikat übernommen hätten. Das ist nicht praktikabel.

Die Beschaffung von validen TLS-Zertifikaten von einer anerkannten CA ist schon lange kein bedeutsamer Aufwand mehr oder eine finanzielle Belastung. Selbst Anfängern gelingt das in kurzer Zeit. Ich muss eingestehen, dass sich Let’s Encrypt für komplexere Setups nicht immer optimal eignet. Doch für einen erfahrenen Administrator sollte auch das keine unüberwindbare Hürde darstellen. Im Zweifel ist eben Kreativität, ein bisschen Scripten oder Handarbeit angesagt. Das sollte einem die Sicherheit der User auf dem eigenen und auf fremden Servern in jedem Fall wert sein.

Viele XMPP-Nutzer verwenden unsere Server als Alternative oder Ergänzung zu WhatsApp. Gerne erklären wir breitspurig, wie sicher doch die Kommunikation via XMPP sei, und dass WhatsApp eine Gefahr für Privatsphäre und Sicherheit darstelle. Tatsächlich müssen wir bei uns selbst anfangen, denn in der Basisversion sind “wir” in der XMPP-Community kein Stück sicherer unterwegs, als WhatsApp-Nutzer. WhatsApp bekommt immerhin Transportverschlüsselung auf die Reihe. Das kann man von uns im Durchschnitt noch nicht behaupten.

Also: Lasst uns das Thema Transportverschlüsselung im XMPP-Netzwerk endlich ernst nehmen und nicht immer nur über Sicherheit reden, sondern dem Taten folgen lassen!


Inzwischen sind ein paar andere Server-Betreiber meinem Aufruf gefolgt und haben es mir gleich getan. Es würde mich freuen, wenn wir das XMPP-Netzwerk bald zu einem sicheren Netzwerk erklären könnten! Konfiguriert eure Server, und sagt es weiter!

Sichere Konfiguration für Prosody:

s2s_require_encryption = true;
s2s_secure_auth = true;
s2s_insecure_domains = {};

Spätestens seit 2013 gibt es Initiativen, die das XMPP-Netzwerk durch Transportverschlüsselung sicherer machen wollen. Mittlerweile unterstützen fast alle öffentlichen XMPP-Server zumindest optional Transportverschlüsselung via TLS oder SSL. Leider wird das Thema nur in den wenigsten Fällen wirklich ernst genommen - und das mache ich u.A. daran fest: In viel zu vielen Fällen können wir bei der Server-to-Server-Kommunikation folgendes finden:

  • Verwendung von selbst signierten Zertifikaten
  • Defekte / ungültige Zertifikatskonfigurationen (fehlendes Intermediate-Cert, abgelaufene Zertifikate, …)
  • Tolerierung unverschlüsselter Verbindungen

Vor allem gegen den letzten Punkt muss unbedingt etwas unternommen werden. Viel zu viele Server priorisieren zwar verschlüsselte Verbindungen, verifizieren angebotene Zertifikate jedoch nicht, und wenn kein Zertifikat angeboten wird, wird via Dialback authentifiziert oder die Verschlüsselung gleich ganz deaktiviert. Besser könnten die Konditionen für MitM-Attacken kaum sein. Man signalisiert damit zwar Bereitschaft, zu verschlüsseln, aber wenn er andere nicht will, oder wenn ein Angreifer auf der Leitung sitzt, dann verschlüsselt man eben nicht. Es leuchtet ein, dass das nicht besonders viel Sinn ergibt. Wenn wir Zertifikate nicht prüfen und bereit sind, die Verschlüsselung zu deaktivieren, damit jemand mit uns spricht, können wir es auch gleich sein lassen, und unverschlüsselt kommunizieren. Der Effekt ist derselbe: Wer mithören will, kann mithören.

Meiner Meinung nach ist es an der Zeit, “Ernst zu machen”, und seriöse Transportverschlüsselung einzuführen. Verpflichtend. Für alle. Ohne Ausnahmen - ohne wenn und aber.

Ich habe damit vor wenigen Tagen angefangen und meinen trashserver.net Dienst so konfiguriert, dass nur noch sichere, verschlüsselte Verbindungen von Servern akzeptiert werden, die ein gültiges TLS-Zertifikat von einer CA besitzen, welche allgemein anerkannt ist. D.h.: Keine Verbindungen mehr zu Servern, die keine oder ungültige Zertifikate besitzen, oder ein selbst signiertes Zertifikat nutzen.

Letztere schließe ich aus einem praktischen Grund aus: Der Aufwand, jedes individuelle Root-Zertifikat eines jeden Betreibers zu importieren und zu pflegen, der ein Self-Signed Zertifikat einsetzt, würde den Rahmen sprengen. Wir postulieren gerne eine XMPP-Welt, in der es möglichst viele Server gibt. Wir können aber nicht jedem kleinen Betreiber hinterherlaufen und sein Root-Zertifikat importieren, geschweige denn pflegen. Bei verpflichtender Verschlüsselung und Authentifizierung über das Zertifikat wäre ein neuer XMPP-Server so lange vom Rest des Netzes abgeschnitten, bis alle anderen Betreiber sein Root-Zertifikat übernommen hätten. Das ist nicht praktikabel.

Die Beschaffung von validen TLS-Zertifikaten von einer anerkannten CA ist schon lange kein bedeutsamer Aufwand mehr oder eine finanzielle Belastung. Selbst Anfängern gelingt das in kurzer Zeit. Ich muss eingestehen, dass sich Let’s Encrypt für komplexere Setups nicht immer optimal eignet. Doch für einen erfahrenen Administrator sollte auch das keine unüberwindbare Hürde darstellen. Im Zweifel ist eben Kreativität, ein bisschen Scripten oder Handarbeit angesagt. Das sollte einem die Sicherheit der User auf dem eigenen und auf fremden Servern in jedem Fall wert sein.

Viele XMPP-Nutzer verwenden unsere Server als Alternative oder Ergänzung zu WhatsApp. Gerne erklären wir breitspurig, wie sicher doch die Kommunikation via XMPP sei, und dass WhatsApp eine Gefahr für Privatsphäre und Sicherheit darstelle. Tatsächlich müssen wir bei uns selbst anfangen, denn in der Basisversion sind “wir” in der XMPP-Community kein Stück sicherer unterwegs, als WhatsApp-Nutzer. WhatsApp bekommt immerhin Transportverschlüsselung auf die Reihe. Das kann man von uns im Durchschnitt noch nicht behaupten.

Also: Lasst uns das Thema Transportverschlüsselung im XMPP-Netzwerk endlich ernst nehmen und nicht immer nur über Sicherheit reden, sondern dem Taten folgen lassen!


Inzwischen sind ein paar andere Server-Betreiber meinem Aufruf gefolgt und haben es mir gleich getan. Es würde mich freuen, wenn wir das XMPP-Netzwerk bald zu einem sicheren Netzwerk erklären könnten! Konfiguriert eure Server, und sagt es weiter!

Sichere Konfiguration für Prosody:

s2s_require_encryption = true;
s2s_secure_auth = true;
s2s_insecure_domains = {};

Zuerst ist ganz wichtig zu wissen, dass Claws-Mail nur read-only Funktion für Carddav unterstützt, und daher eine Bearbeitung unmöglich ist.

Vorbereitung

Wir brauchen vdirsyncer, wie das installiert wird ist hier beschrieben. Dann brauchen wir einige Ordner, die wie mir dem folgenden Befehl anlegen:

    mkdir ~/.vdirsyncer
    mkdir ~/.contacts

Konfiguration

Jetzt erstellen wir die grundlegende Konfiguration von vdirsyncer:

vim ~/.vdirsyncer/config

Die Konfiguration sollte wie folgt aussehen

[general]
status_path = "~/.vdirsyncer/status/"

[storage local]
type = "singlefile"
path = "~/.contacts/%s.vcf"

[storage online]
type = "carddav"
url = "CARDDAV_LINK"
username = "USERNAME"
password = "PASSWORD"

[pair contacts]
a = "local"
b = "online"
collections = ["from a", "from b"]
conflict_resolution = "b wins"

Fragen zu der Konfiguration entnehmt ihr bitte dem Docs von vdirsyncer. Wichtig ist das ihr hier noch Benutzername, Password und den Url anpasst.

Sync

Jetzt lassen wir vdirsyncer die Syncronisation durchführen:

vdirsyncer discover
vdirsyncer sync

Claws Mail

Öffne Claws-Mail. Gehe zu Extras => Adressbuch.

Klicke zu Adressbuch => Neue vCard. Wähle einen Namen für das Adressbuch.

Über den Dursuchen Dialog finden wie die vCard in dem Ordner ~/.contacts/. Auf OK klicken und wir sehen die Kontakte.

Wichtig: Claws-Mail zeigt nur die Kontakte an, die eine Mailadresse haben.

Crontab

Am Ende richten wir noch eine automatische syncronisation ein, die alle 30 Minuten die Kontakte aktualisiert.

contab -e

Am Ende folgendes einfügen

*/30 * * * * /usr/local/bin/vdirsyncer sync > /dev/null

Das wars

Zuerst ist ganz wichtig zu wissen, dass Claws-Mail nur read-only Funktion für Carddav unterstützt, und daher eine Bearbeitung unmöglich ist.

Vorbereitung

Wir brauchen vdirsyncer, wie das installiert wird ist hier beschrieben. Dann brauchen wir einige Ordner, die wie mir dem folgenden Befehl anlegen:

    mkdir ~/.vdirsyncer
    mkdir ~/.contacts

Konfiguration

Jetzt erstellen wir die grundlegende Konfiguration von vdirsyncer:

vim ~/.vdirsyncer/config

Die Konfiguration sollte wie folgt aussehen

[general]
status_path = "~/.vdirsyncer/status/"

[storage local]
type = "singlefile"
path = "~/.contacts/%s.vcf"

[storage online]
type = "carddav"
url = "CARDDAV_LINK"
username = "USERNAME"
password = "PASSWORD"

[pair contacts]
a = "local"
b = "online"
collections = ["from a", "from b"]
conflict_resolution = "b wins"

Fragen zu der Konfiguration entnehmt ihr bitte dem Docs von vdirsyncer. Wichtig ist das ihr hier noch Benutzername, Password und den Url anpasst.

Sync

Jetzt lassen wir vdirsyncer die Syncronisation durchführen:

vdirsyncer discover
vdirsyncer sync

Claws Mail

Öffne Claws-Mail. Gehe zu Extras => Adressbuch.

Klicke zu Adressbuch => Neue vCard. Wähle einen Namen für das Adressbuch.

Über den Dursuchen Dialog finden wie die vCard in dem Ordner ~/.contacts/. Auf OK klicken und wir sehen die Kontakte.

Wichtig: Claws-Mail zeigt nur die Kontakte an, die eine Mailadresse haben.

Crontab

Am Ende richten wir noch eine automatische syncronisation ein, die alle 30 Minuten die Kontakte aktualisiert.

contab -e

Am Ende folgendes einfügen

*/30 * * * * /usr/local/bin/vdirsyncer sync > /dev/null

Das wars

17. Januar 2017

Mit der Zeit häufen sich auf XMPP-Servern unzählige ungenutzte XMPP-Accounts an. Es schadet nicht, diese nach einem festgelegten Zeitraum zu löschen und die Benutzernamen wieder freizugeben. Nicht zuletzt kann so eine Reinigungsaktion auch für die Datenbank-Performance hilfreich sein. Standardmäßig enthält Prosody leider keinen Mechnismus zum Löschen inaktiver Accounts, doch mit zwei Modulen und ein paar Kommandozeilen-Tricks kann man den Server von Altlasten befreien. Um zu erkennen, welcher Account wann zuletzt genutzt wurde, muss der Zeitpunkt der letzten Aktivität (dazu zählen Registrierung, Login, Logout) für jeden Account ermittelt werden.

Mit der Zeit häufen sich auf XMPP-Servern unzählige ungenutzte XMPP-Accounts an. Es schadet nicht, diese nach einem festgelegten Zeitraum zu löschen und die Benutzernamen wieder freizugeben. Nicht zuletzt kann so eine Reinigungsaktion auch für die Datenbank-Performance hilfreich sein. Standardmäßig enthält Prosody leider keinen Mechnismus zum Löschen inaktiver Accounts, doch mit zwei Modulen und ein paar Kommandozeilen-Tricks kann man den Server von Altlasten befreien.

Um zu erkennen, welcher Account wann zuletzt genutzt wurde, muss der Zeitpunkt der letzten Aktivität (dazu zählen Registrierung, Login, Logout) für jeden Account ermittelt werden. Dazu gibt es das prosody-Modul “mod_lastlog”. Darauf kann das zweite Modul “mod_list_inactive” aufbauen: Es nutzt die von mod_lastlog bereitgestellten Aktivitäts-Timestamps und gibt auf Wunsch eine Liste der Nutzer-IDs aus, welche in dem vorgegebenen Zeitraum nicht aktiv waren.

Die beiden Module findet ihr im Modul-Repository

Aktiviert die beiden Module wie üblich und startet den Prosody-Server neu.

Inaktive Nutzer ermitteln

Mit der ersten Aufräumaktion solltet ihr erst beginnen, wenn der von euch mindesten geforderte Nutzungszeitraum 1x durchlaufen wurde. Ich habe vor etwa einem Jahr die beiden Module installiert. Seitdem wurde mitprotokolliert, wann Nutzer (wie oben definiert) aktiv waren. Weil ich in den Nutzungsbedingungen festgelegt habe, dass Accounts nach einem Jahr Nichtnutzung gelöscht werden, habe ich die Löschaktion heute zum ersten Mal ausgeführt.

In der einfachsten Variante kann man sich eine Liste der Nutzer ausgeben lassen, die sich seit einem Jahr (oder länger) nicht mehr ein- oder ausgeloggt haben:

prosodyctl mod_list_inactive trashserver.net 1year default

(die Syntax des Befehls könnt ihr via prosodyctl mod_list_inactive nachschlagen)

Wer einfach nur gerne die Anzahl der betroffenen Nutzer ermitteln will, kann dem Kommendo ein | wc -l anhängen:

prosodyctl mod_list_inactive trashserver.net 1year default | wc -l

In meinem Fall waren das 408 Benutzer, die sich zum Teil noch nicht ein einziges Mal eingeloggt haben.

Betroffene Accounts löschen

( … und an dieser Stelle solltet ihr vorsichtshalber ein Backup anlegen …)

Mit der Ausgabe des list_inactive Module können leider nicht direkt etwas anfangen. Es gibt zwar noch zwei andere Ausgabearten, doch die “delete” Ausgabe hilft uns nur, wenn wir zum Löschen ein kleines Lua-Script basteln wollen. Da ich und viele andere Lua nicht beherrschen, habe ich mir etwas anderes überlegt: Mithilfe der Ausgabe wird einfach ein Bash-Script generiert, das zum Löschen der Accounts ausgeführt wird.

prosodyctl mod_list_inactive trashserver.net 1year default | sed -e 's/^/prosodyctl deluser /' > delusers.sh

mit “delusers.sh” habt ihr jetzt eine Scriptdatei an der Hand, die den passenden prosodyctl-Befehl zum löschen eines jeden Accounts bereits enthält. Sie muss jetzt nur noch ausgeführt werden:

bash delusers.sh

Je nach Anzahl der zu löschenden Accounts kann es einige Momente dauern, bis alle Löschbefehle durchgelaufen sind. Zur Kontrolle können nocheinmal die inaktiven Benutzer gezählt werden:

prosodyctl mod_list_inactive trashserver.net 1year default | wc -l

Wenn der Zähler diesmal auf 0 steht, war die Aktion erfolgreich.

Homeserver bzw. Netzwerkspeicher sind hinsichtlich des Datenschutzes deutlich attraktiver als Cloudspeicher bei Drittanbietern. Neben den Hardwarekosten fallen jedoch auch Betriebskosten an und die sind je nach Hardware nicht zu vernachlässigen.

Im professionellen Einsatz haben Server natürlich bestenfalls eine sehr hohe Erreichbarkeit. Bei einem Homeserver oder NAS sieht das aber schon deutlich anders aus. Ist der Netzwerkspeicher von außerhalb des Heimnetzes nicht zu erreichen und niemand zu Hause, muss das Gerät eigentlich nicht in Betrieb sein.

Openmediavault bietet hierfür mit WOL und Autoshutdown zwei nützliche Werkzeuge an.

Wake on Lan (WOL) und automatisches Herunterfahren sind keine Exklusivfunktionen von openmediavault, allerdings bei anderen Linux-Distributionen nicht derart einfach zu nutzen. Das Script zum automatisierten Herunterfahren lässt das NAS unter festgelegten Kriterien in einen festgelegten Zustand (Standby, Herunterfahren) wechseln. Wake On Lan ermöglicht es das Gerät ohne physischen Zugriff wieder hochzufahren.

Wake-On-Lan (WOL)

Mit Wake on Lan bezeichnet man einen Vorgang, bei dem ein Rechner per Fernzugriff mittels eines so genannten "Magic Packet" eingeschaltet wird. WOL muss von dem einzuschaltenden Gerät grundsätzlich unterstützt werden. Meistens gibt es im BIOS eine entsprechende Einstellung, die aktiviert sein muss. Ohne eine WOL-Unterstützung macht ein automatisiertes Herunterfahren keinen Sinn, da der Server dann immer manuell gestartet werden muss.

Unterstützt das Gerät WOL reicht es im control panel von OMV unter Netzwerk im Reiter Schnittstellen die Ethernet-Schnittstelle (unter der Voraussetzung der Server hängt via Ethernetanschluss im Netzwerk) zu bearbeiten. Im Bereich Erweiterte Einstellungen muss WOL aktiviert werden.

wol aktivieren

OMV ist lediglich ein Aufsatz für Debian. Daher lassen sich Einstellungen grundsätzlich auch auf der Kommandozeile vornehmen. Wer lieber hier Änderungen vornimmt kann dies mittels Ethtool erledigen. Die aktuelle Konfiguration kann man mittels folgendes Kommandos überprüfen:

ethtool eth0

Bei aktiviertem WOL sollte die Ausgabe die zwei folgenden Zeilen enthalten:

Supports Wake-on: pumbg

Wake-on: g

Um WOL automatisch beim Start des Systems zu aktivieren muss die Passage zur Ethnernet-Schnittstelle in /etc/interfaces/network um folgende Zeile(n) ergänzt werden (fett markiert):

# eth0 network interface

auto eth0

allow-hotplug eth0

iface eth0 inet dhcp

    pre-down ethtool -s $IFACE wol g

iface eth0 inet6 manual

    pre-down ip -6 addr flush dev $IFACE

Wie gesagt, einfacher ist dies definitiv im control panel von OMV, aber manchmal lohnt sich ein Blick in den Maschinenraum, vor allem wenn es mal nicht so funktioniert, wie es sollte.

Gestartet wird das Gerät anschließend mit einem - je nach Betriebssystem unterschiedlichen - Werkzeug. Unter Linux ist wakeonlan recht komfortabel zu bedienen, das im Gegensatz zu etherwake auch keine Rootrechte benötigt. Unter macOS gibt es im App Store einige Programme mit der gewünschten Funktion.

Grundsätzlich benötigt man zum Aufwecken eines Gerätes dessen IP-Adresse im Netzwerk sowie die MAC Adresse. Die meisten macOS-Tools scannen das Netzwerk automatisch um die benötigten Informationen zu ermitteln. Bei Linux muss man dies natürlich manuell erledigen, beispielsweise mittels:

ifconfig eth0 | grep "Hardware Adresse"

Automatisches Herunterfahren

Um den Server automatisch abzuschalten muss zuerst das entsprechende Paket installiert werden:

apt-get install openmediavault-autoshutdown

Hierbei handelt es sich um eine exklusive Funktion von OMV. Ein normales Debian-System kann zwar zeitbasiert heruntergefahren werden, aber nicht z.B. nach bestimmten Kriterien. Im OMV control panel lässt sich die Funktion im Abschnitt Dienste unter AutomatischHerunterfahren konfigurieren.

automatisch herunterfahren

Hier kann man bestimmte Kriterien festlegen, nach denen das System automatisch herunterfahren soll. Im hiesigen Beispiel wird das NAS heruntergefahren wenn ein bestimmter PC nicht mehr aktiv ist (IP-Nummer xxx.xxx.xxx.55), da der Netzwerkspeicher dann nicht mehr benötigt wird. Welche genauen Kriterien hier sinnvoll sind hängt im individuellen Nutzungsszenario ab.

Sollte es Probleme geben lohnt sich ein Blick in die Logdatei des Autoshutdown-Scripts. Manchmal sind bestimmte Dienste eingeschaltet und verhindern ein herunterfahren. Nach einer frischen Neuinstallation von OMV gab es hier z.B. ein Problem mit dem Dienst tftpd, der zwar im control panel abgeschaltet war aber von systemd weiterhin gestart wurde. Nach dem deaktivieren des Dienstes via SSH fuhr der Server wie gewünscht automatisch herunter nachdem der Haupt-PC ausgeschaltet wurde.

Homeserver bzw. Netzwerkspeicher sind hinsichtlich des Datenschutzes deutlich attraktiver als Cloudspeicher bei Drittanbietern. Neben den Hardwarekosten fallen jedoch auch Betriebskosten an und die sind je nach Hardware nicht zu vernachlässigen.

Im professionellen Einsatz haben Server natürlich bestenfalls eine sehr hohe Erreichbarkeit. Bei einem Homeserver oder NAS sieht das aber schon deutlich anders aus. Ist der Netzwerkspeicher von außerhalb des Heimnetzes nicht zu erreichen und niemand zu Hause, muss das Gerät eigentlich nicht in Betrieb sein.

Openmediavault bietet hierfür mit WOL und Autoshutdown zwei nützliche Werkzeuge an.

Wake on Lan (WOL) und automatisches Herunterfahren sind keine Exklusivfunktionen von openmediavault, allerdings bei anderen Linux-Distributionen nicht derart einfach zu nutzen. Das Script zum automatisierten Herunterfahren lässt das NAS unter festgelegten Kriterien in einen festgelegten Zustand (Standby, Herunterfahren) wechseln. Wake On Lan ermöglicht es das Gerät ohne physischen Zugriff wieder hochzufahren.

Wake-On-Lan (WOL)

Mit Wake on Lan bezeichnet man einen Vorgang, bei dem ein Rechner per Fernzugriff mittels eines so genannten "Magic Packet" eingeschaltet wird. WOL muss von dem einzuschaltenden Gerät grundsätzlich unterstützt werden. Meistens gibt es im BIOS eine entsprechende Einstellung, die aktiviert sein muss. Ohne eine WOL-Unterstützung macht ein automatisiertes Herunterfahren keinen Sinn, da der Server dann immer manuell gestartet werden muss.

Unterstützt das Gerät WOL reicht es im control panel von OMV unter Netzwerk im Reiter Schnittstellen die Ethernet-Schnittstelle (unter der Voraussetzung der Server hängt via Ethernetanschluss im Netzwerk) zu bearbeiten. Im Bereich Erweiterte Einstellungen muss WOL aktiviert werden.

wol aktivieren

OMV ist lediglich ein Aufsatz für Debian. Daher lassen sich Einstellungen grundsätzlich auch auf der Kommandozeile vornehmen. Wer lieber hier Änderungen vornimmt kann dies mittels Ethtool erledigen. Die aktuelle Konfiguration kann man mittels folgendes Kommandos überprüfen:

ethtool eth0

Bei aktiviertem WOL sollte die Ausgabe die zwei folgenden Zeilen enthalten:

Supports Wake-on: pumbg

Wake-on: g

Um WOL automatisch beim Start des Systems zu aktivieren muss die Passage zur Ethnernet-Schnittstelle in /etc/interfaces/network um folgende Zeile(n) ergänzt werden (fett markiert):

# eth0 network interface

auto eth0

allow-hotplug eth0

iface eth0 inet dhcp

    pre-down ethtool -s $IFACE wol g

iface eth0 inet6 manual

    pre-down ip -6 addr flush dev $IFACE

Wie gesagt, einfacher ist dies definitiv im control panel von OMV, aber manchmal lohnt sich ein Blick in den Maschinenraum, vor allem wenn es mal nicht so funktioniert, wie es sollte.

Gestartet wird das Gerät anschließend mit einem - je nach Betriebssystem unterschiedlichen - Werkzeug. Unter Linux ist wakeonlan recht komfortabel zu bedienen, das im Gegensatz zu etherwake auch keine Rootrechte benötigt. Unter macOS gibt es im App Store einige Programme mit der gewünschten Funktion.

Grundsätzlich benötigt man zum Aufwecken eines Gerätes dessen IP-Adresse im Netzwerk sowie die MAC Adresse. Die meisten macOS-Tools scannen das Netzwerk automatisch um die benötigten Informationen zu ermitteln. Bei Linux muss man dies natürlich manuell erledigen, beispielsweise mittels:

ifconfig eth0 | grep "Hardware Adresse"

Automatisches Herunterfahren

Um den Server automatisch abzuschalten muss zuerst das entsprechende Paket installiert werden:

apt-get install openmediavault-autoshutdown

Hierbei handelt es sich um eine exklusive Funktion von OMV. Ein normales Debian-System kann zwar zeitbasiert heruntergefahren werden, aber nicht z.B. nach bestimmten Kriterien. Im OMV control panel lässt sich die Funktion im Abschnitt Dienste unter AutomatischHerunterfahren konfigurieren.

automatisch herunterfahren

Hier kann man bestimmte Kriterien festlegen, nach denen das System automatisch herunterfahren soll. Im hiesigen Beispiel wird das NAS heruntergefahren wenn ein bestimmter PC nicht mehr aktiv ist (IP-Nummer xxx.xxx.xxx.55), da der Netzwerkspeicher dann nicht mehr benötigt wird. Welche genauen Kriterien hier sinnvoll sind hängt im individuellen Nutzungsszenario ab.

Sollte es Probleme geben lohnt sich ein Blick in die Logdatei des Autoshutdown-Scripts. Manchmal sind bestimmte Dienste eingeschaltet und verhindern ein herunterfahren. Nach einer frischen Neuinstallation von OMV gab es hier z.B. ein Problem mit dem Dienst tftpd, der zwar im control panel abgeschaltet war aber von systemd weiterhin gestart wurde. Nach dem deaktivieren des Dienstes via SSH fuhr der Server wie gewünscht automatisch herunter nachdem der Haupt-PC ausgeschaltet wurde.

16. Januar 2017

Die Entwickler-Werkzeuge von Firefox wurden in den letzten Jahren immer mächtiger und machen Erweiterungen wie Firebug mittlerweile überflüssig. Mozilla plant nun die Auslagerung als System-Add-on, um Verbesserungen noch schneller an die Nutzer ausliefern zu können. Außerdem sollen die Entwickler-Werkzeuge optional gemacht werden, so dass diese erst auf den ausdrücklichen Wunsch des Nutzers hin aktiviert werden.

Als Teil des Go Faster-Programms entkoppelt Mozilla einzelne Funktionen vom Firefox-Core und integriert diese als gebündelte Add-ons. Dadurch können Verbesserungen unabhängig von regulären Firefox-Updates ausgeliefert werden. Eine komplette Übersicht überalle bisherigen System-Add-ons von Firefox gibt es hier.

Ganz in diesem Sinne möchte Mozilla nun auch die Entwickler-Werkzeuge vom Firefox-Core entkoppeln und in Form eines System-Add-ons ausliefern. Die Haupt-Motivation ist auch hier wieder die Möglichkeit, Verbesserungen für die Nutzer, in dem Fall Entwickler von Webseiten, schneller ausliefern zu können und nicht an den Release-Zyklus von Firefox gebunden zu sein.

Während die meisten System-Add-ons nicht einfach per Oberfläche deaktivierbar sind (de facto ist dies ausschließlich Pocket), möchte Mozilla die Entwickler-Werkzeuge für den Nutzer optional machen, so dass diese erst auf den Wunsch des Nutzers hin aktiviert werden. Die genauen Details, wie die Integration aussehen soll, befinden sich noch in der Diskussion. Sicher ist bisher nur, dass man die Aktivierung so leicht wie möglich machen möchte. Vorbilder sind hier Apple mit Safari und Microsoft mit Edge. So ist es beispielsweise denkbar, dass Firefox auch bei deaktivierten Entwickler-Werkzeugen auf wichtige Tastenkombinationen der Entwickler-Werkzeuge reagiert, um den Nutzer zu fragen, ob die Entwickler-Werkzeuge aktiviert werden sollen.

Der Beitrag Firefox: Entwickler-Werkzeuge sollen optional werden erschien zuerst auf soeren-hentzschel.at.

Nachdem nun dieses Blog und die Microsite für meinen XMPP-Server auf statischen HTML-Dateien basieren, will ich eine Einführung in den Static Site Generator “Hugo” geben. Static Site Generatoren gibt es mittlerweile wie Sand am Meer. Einen Überblick kann man sich beispielsweise auf der Seite staticgen.com verschaffen. Hugo gefällt mir im Hinblick auf Geschwindigkeit und Einfachkeit allerdings am besten. Hervorzuheben ist außerdem die besonders einfache Installation: Zur Einrichtung wird einfach die passende Programmdatei als Executable heruntergeladen.

Nachdem nun dieses Blog und die Microsite für meinen XMPP-Server auf statischen HTML-Dateien basieren, will ich eine Einführung in den Static Site Generator “Hugo” geben. Static Site Generatoren gibt es mittlerweile wie Sand am Meer. Einen Überblick kann man sich beispielsweise auf der Seite staticgen.com verschaffen. Hugo gefällt mir im Hinblick auf Geschwindigkeit und Einfachkeit allerdings am besten. Hervorzuheben ist außerdem die besonders einfache Installation: Zur Einrichtung wird einfach die passende Programmdatei als Executable heruntergeladen. Weitere Abhängigkeiten müssen nicht erfüllt werden.

Bevor es losgeht

… will ich kurz zusammenfassen, was Hugo ist und wie es funktioniert:

  • Inhalte für die Website werden in Markdown-Syntax oder in HTML lokal verfasst. Dazu wird ein beliebiger Text-Editor genutzt.
  • Das Design wird durch ein Theme bestimmt, welches Elemente aus der Go-Templatesprache verwendet.
  • Hugo wendet auf jede der verfassten Markdown- oder HTML-Seiten das Theme an und erzeugt fertige HTML Seiten. Daneben werden z.B. auch RSS-Feed, Sitemap und Übersichtsseiten automatisch generiert.
  • Die generierten HTML-Dateien können jetzt auf einem einfachen Webserver / Webspace veröffentlicht werden.

Download und Installation

Auf der GitHub Release-Seite des Projekts können die aktuellen Binaries heruntergeladen werden. Unter Linux wird die ausführbare Datei einfach in das benutzerdefinierte Programmverzeichnis geschoben, z.B.:

cd ~/Downloads
wget https://github.com/spf13/hugo/releases/download/v0.18.1/hugo_0.18.1_Linux-64bit.tar.gz
tar -xf hugo_0.18.1_Linux-64bit.tar.gz
sudo mv hugo_0.18.1_linux_amd64/hugo_0.18.1_linux_amd64 /usr/local/bin/hugo

Danach ist der Befehl “hugo” sofort im Terminal verfügbar.

Ein Hugo-Projekt erstellen

Im nächsten Schritt sucht ihr euch ein Verzeichnis, in dem ihr alle Projektdateien für ein Website-Projekt aufbewahren wollt. Navigiert dann im Terminal in dieses Verzeichnis und führt ein

hugo new site ./

aus. Dieser Befehl generiert den Grundstock für eure Microsite. Der Verzeichnisinhalt sollte nun in etwa so aussehen:

  • archetypes
  • config.toml (Grundkonfiguration der Site)
  • content (Enthält alle Seiten in Markdown- oder HTML-Format)
  • data
  • layouts
  • static (enthält statische Dateien und Verzeichnisse)
  • themes

Passt zunächst den Inhalt der Website-Konfiguration in config.toml an, z.B. so:

languageCode = "de-de"
title = "Meine Hugo-Site"
baseurl = "https://meinehugosite.tld"

Ein Theme herunterladen

Hugo kommt ohne Default-Theme. Würden jetzt Seiten erzeugt werden, würde man nichts als einen weißen Bildschirm sehen. Lasst uns als nächstes also ein Theme von https://themes.gohugo.io/ herunterladen und in das themes/ Verzeichnis kopieren. Das “Hemingway” Theme eignet sich hervorragend für einen kleinen Blog:

cd themes
git clone https://github.com/tanksuzuki/hemingway.git
cd ../

Nun muss das Theme noch in der Konfigurationsdatei config.toml als solches festgelegt werden:

languageCode = "de-de"
title = "Meine Hugo-Site"
baseurl = "https://meinehugosite.tld"
theme = "hemingway"

Erste Inhalte erstellen

Nehmen wir an, die Site soll ein Blog sein, und ein neuer Blogpost soll erstellt werden. Mit dem Kommando

hugo new post/hallo-welt.md

wird eine neue Seite in Markdown-Format generiert. Diese liegt nun im Unterverzeichnis content/post/. Wenn ihr die Datei öffnet, sehr ihr, dass diese bereits folgendes beinhaltet:

+++
date = "2017-01-17T09:28:11+01:00"
title = "hallo welt"
+++

Dieser Kopfbereich - eingerahmt in “+++” enthält wichtige Metadaten für die jeweilige Seite / den jeweiligen Blogpost. In diesem Fall werden nur Seitentitel und Datum festgelegt. Allerdings können hier später auch Tags, Autor und beliebige weitere Metadaten zum Beitrag angegeben werden.

Der eigentliche Inhalt der Seite wird unter diesem Kopfbereich formuliert, z.B.

+++
date = "2017-01-17T09:28:11+01:00"
title = "Hallo Welt!"
+++
## Mein erster Beitrag
Dies ist mein erster Blogbeitrag im neuen **Hugo**-generierten Blog!

Ich empfehle euch, an dieser Stelle einen Blick auf das Markdown-Cheatsheet zu werfen. “##” leitet eine <h2>-Überschrift ein; “**” markiert einen Abschnitt fett.

Die Seite in der Live-Vorschau betrachten

Hugo verfügt über eine ausgeklügelte Live-Vorschau-Funktion. Ihr könnt den aktuellen Stand eurer Seite im Webbrowser betrachten, während ihr noch an den Inhalten (oder später evtl. am Theme) arbeitet. Bei jedem Abspeichern der bearbeiteten Datei aktualisiert Hugo die Vorschau im Webbrowser. Um die Vorschaufunktion zu starten, gebt folgenden Hugo-Befehlk ein:

hugo -D serve

Die -D Option sorgt dafür, dass auch als “draft” markierte Inhalte berücksichtigt werden. Ein Beitrag, der im Kopfbereich ein draft = true enthält, wird bei einem hugo später nicht veröffentlicht und wird auch bei einem einfachen hugo serve ignoriert, wenn die -D Flag fehlt.

Eure Site könnt ihr jetzt im Webbrowser unter der Adresse http://localhost:1313/ betrachten. Auf der Übersichtsseite sollte schon euer erster Blogpost zu sehen sein. Ihr könnt ihn öffnen, und den Inhalt des Posts im Texteditor ändern. Beim Speichern der Änderungen sollte die Seite im Browser automatisch aktualisiert werden. So kann man sehr bequem Inhalte formulieren und formatieren, und die Änderungen am Quellcode z.B. auf einem zweiten Monitor kontrollieren.

Der URL des neuen Posts entspricht übrigens dem Pfad, der beim “hugo new” Kommando angegeben wurde: /post/hallo-welt/ (ohne Dateiendung). Für jede Seite kann also invididuell bestimmt werden, unter welchem URL sie verfügbar sein soll.

Bilder und andere Dateien einbinden

Als Speicherort für alle Dateien, die abseits des Seitentextes verfügbar gemacht werden sollen, steht das “static” Verzeichnis zur Verfügung. Legt im “static” Verzeichnis ein neues Verzeichnis “images” an und speichert ein Bild Namens “test.jpg” darin.

Dieses Bild kann nun im Beitrag wie folgt eingebettet werden:

## Mein erster Beitrag
Dies ist mein erster Blogbeitrag im neuen **Hugo**-generierten Blog!
![Beispielbild-Beschreibung](/images/test.jpg)

Live-Ansicht

HTML-Seiten generieren und hochladen

Wenn die ersten Inhalte fertiggestellt sind, kann das Verzeichnis mit den statischen HTML-Dateien generiert werden, welches auf einen Webserver hochgeladen wird. Zum Generieren reicht ein

hugo

aus. Danach erscheint ein neuer Ordner “public” im Projekt-Wurzelverzeichnis. Der Inhalt dieses Verzeichnisses kann nun z.B. via rsync (SSH) oder FTP zum Webserver hochgeladen werden:

rsync -ave ssh public root@meinserver.tld:/var/www/

Das war’s für’s erste! In einem Folgebeitrag will ich euch erklären, wie ihr ein eigenes, einfaches Theme für eure Site erstellen könnt. Bis dahin könnt ihr noch ein wenig experimentieren oder euch die offizielle Hugo-Dokumentation ansehen.

Update: Der zweite Teil zum Thema “Eigenes Hugo Theme erstellen” ist jetzt online: https://legacy.thomas-leister.de/einfuehrung-in-hugo-theme-erstellen/

Drei verschlüsselnde Messenger im Praxistest, ein Teil meines Versuches, die Datenhygiene zu verbessern.

Versuch 1: Ring

Der erste von mir ausprobierte Messenger war Ring. Ring klingt genial. Es hat Clients für Windows, Mac OS und Linux, sowie für Android. Es ist nicht nur freie Software, sondern gar ein GNU-Projekt. Zwar noch nicht als stabile Version veröffentlicht gibt es immerhin eine zweite Beta, die Grundlagen sollten also da sein.

Und genau das stimmt nicht. Ring funktioniert schlicht gar nicht. Die erste Enttäuschung war der Linux-Client, den ich erst gar nicht installiert bekommen habe, und der wohl auf DBus und Pulseaudio aufsetzt, also auch unbrauchbar wäre. Dann der Android-Client. Der sieht zwar erstmal hübsch aus und ist installierbar, aber einen Kontakt hinzufügen, das klappte nur in einem von zwei Testversuchen reibungslos. Im Problemfall brauchte es viele Versuche und funktionierte erst mit mehrtägiger Verzögerung, dabei waren wir im gleichen Raum. Immerhin funktionierte es. Aber miteinander schreiben, das funktionierte dann wieder nicht immer. Oft genug kamen Nachrichten nicht an, musste Ring neu gestartet werden, damit dann neu gesendete Nachrichten ankommen konnten. Sprachnachrichten oder gar Video, das funktionierte nur kurz oder gar nicht, dann brach die Verbindung weg oder stürzte das Programm ab, oder das Bild blieb schwarz. Störend auch einfachste UX-Fehler, beispielsweise wird beim Schreiben einer Nachricht das Keyboard ausgeklappt, aber danach im Nachrichtenfenster nicht zum Ende zurückgescrollt, während des Chattens müsste man also nach jedem Senden einer Nachricht nach unten scrollen.

Versuch 2: Tox

Der zweite Messenger war Tox. Tox klingt auf der Webseite ebenfalls sehr gut. Normale Anrufe und Videoanrufe werden unterstützt, es sei verschlüsselt, dezentral und frei. Es gibt eine Vielzahl von Linux-Client, was wirklich sehr sympathisch ist, wobei qTox auch unter Windows und OSX funktionieren soll, generell die Multiplattformfähigkeiten von qt ausnutzt. Aber für Android, für Android gibt es nur Antox. Und Antox, darüber hätte ich mir meine Meinung per F-Droid bilden können, das dessen Installation gesperrt hat, weil das Programm zwar kompiliere aber nicht wirklich funktioniere.

Denn genau so ist es. Antox, dann aus dem Play Store installiert, stürzt einfach ab, und das immer wieder. Anruf starten -> Absturz. Miteinander schreiben -> Absturz. Das Chatten stürzt nicht immer ab, die Oberfläche des Programms wirkt sonst auch gut, das Hinzufügen war nicht ganz so problematisch wie bei Ring, wenn auch nicht reibungslos. Aber trotzdem ist es unmöglich, es so als Messenger zu nutzen. Und, was es dann auch als Chatclient kaputtmacht: Ist der Gesprächspartner offline, was scheinbar automatisch passiert wenn Antox eine Weile nicht benutzt wurde, kann man ihm keine Nachricht schicken. Tox ist also auch unbrauchbar, zumindest auf Android.

Versuch 3: Kontalk

Der dritte Versuch lief dann mit Kontalk, und der läuft noch. Ich kann also gleich vorwegnehmen: Das ist eine andere Liga und funktioniert ganz gut. Vielleicht ist das nicht so verwunderlich, denn anstatt das Rad neu zu erfinden nutzt Kontalk XMPP, wohl mit eigenen Erweiterungen. Es ist ebenfalls frei, und es gibt Clients für Android und die drei großen Desktops, per Java. Zusätzlich zu älterer Technik im Hintergrund ist das Projekt in seinen Ansprüchen also wesentlich bescheidener. Mir soll es recht sein, wenn es denn gut funktioniert.

Darüber kann man nun etwas streiten. Das Hinzufügen meines Kontaktes lief problemlos. Die Telefonnummer funktioniert als Identifikator, anonym ist es also nicht, aber immerhin komfortabel. Miteinander schreiben, das funktioniert auch einwandfrei. Allerdings gibt es keine Anruffunktion, der Button dafür ruft den Gesprächspartner schlicht über die Simkarte an. Videoanrufe gibt es dann natürlich auch nicht. Sprachnachrichten können dafür wie eine Chatnachricht gesendet werden, war zwar nett ist, aber trotzdem eine Krücke bleibt. Kontalk ist also ein guter Ersatz für einen einfachen Chatclient, aber kein Ersatz für Skype.

Alternativen

Kontalk funktioniert also, ist aber nicht ideal. Es gäbe ja durchaus noch ein paar Alternativen. Whatsapp verschlüsselt nun standardmäßig, ist aber nicht frei und hat daher mein Vertrauen nicht. Signal klingt super, verlangt aber so viele Rechte auf Android, dass ich denen auch gleich das Telefon samt Passwort per Post zuschicken könnte. Die Empfehlung von Snowden ist zwar mehr als nett, aber dass sie nicht mit einer Version auf F-Droid einhergeht verstört mich. Telegram klingt ebenfalls gut und ist auch frei, aber dessen Verschlüsselung wurde damals heftigst kritisiert. Threema ist nicht kostenlos, aber vor allem nicht frei.

Neben Telegram sind also insbesondere Wire und Riot auf meiner Liste. Die sind in der gleichen Größenordnung wie Ring und Tox, also mögliche Skype-Alternative. Silence als optionaler SMS-Verschlüssler klingt auch nett, das könnte gegebenenfalls eine einfachere Alternative für Kontalk sein.

Wer kennt noch mehr Alternativen, und hat eventuell sogar eigene Erfahrungen?

Ich habe mich entschieden und meinen xmpp/jabber Server frei verfügbar gemacht.
Jeder der Interesse hat, kann sich bei mir einen Account anlegen.

Ich freue mich auf reges Interesse und zahlreiche User, die das Angebot nutzen.

Mein Server: gnude.no-ip.biz

Webseite mit Statusmeldungen: http://www.nitschke-marl.de/jabberserver.html

Der Server läuft auf einem P4 mit 2 Ghz und Ubntu 10.04.4

google-erg_220px-xmpp_logo-svg

15. Januar 2017

Wem das Standard-Design von Firefox nicht gefällt, kann das Aussehen von Firefox durch die Installation sogenannter Themes verändern. In diesem Jahr dreht sich vieles um Themes: angefangen mit Firefox 53 und der standardmäßigen Auslieferung zweier Kompakt-Themes zusätzlich zum Standard-Theme, über eine neue Theming-API für Drittanbieter bis hin zu einem neuen Standard-Design von Firefox.

Firefox 53: Themes werden im Add-on Manager beworben

Wer Themes installiert hat, kann diese über den Add-on Manager von Firefox aktivieren oder deinstallieren. Einen Hinweis, wie man überhaupt zu neuen Themes gelangt, gibt es innerhalb des Add-on Managers bisher nicht. Zumindest über Menü → Anpassen gibt es unten innerhalb der Theme-Auswahl einen Verweis auf die Themes-Seite von Mozilla.

Ab Firefox 53 (erscheint nach aktueller Planung am 18. April 2017) gibt es einen sehr gut sichtbaren Hinweis direkt im Add-on Manager von Firefox, welcher auf die Themes-Seite von Mozilla verlinkt und es damit einfacher macht, neue Themes zu entdecken beziehungsweise überhaupt zu verstehen, wozu dieser Abschnitt des Add-on Managers eigentlich ist, falls dies dem Anwender noch nicht klar ist.

Themes Firefox 53

Geändert hat sich in diesem Zusammenhang auch das dargestellte Symbol für das Standard-Design.

In gleichem Stil gibt es ab Firefox 52 übrigens im Plugin-Abschnitt des Add-on Managers auch einen Hinweis bezüglich der eingestellten Unterstützung von NPAPI-Plugins (außer Adobe Flash), so dass sich Anwender nicht über fehlende Plugins wie Java oder Silverlight wundern.

Plugins Firefox 53

Firefox 53: Auslieferung zweier Kompakt-Themes

Ebenfalls neu ab Firefox 53 ist die Tatsache, dass der Anwender ohne weiteres Zutun nicht mehr länger nur das Standard-Design zur Auswahl hat, sondern zwei zusätzliche, sogenannte kompakte Themes.

Nutzern der Developer Edition von Firefox kommen diese möglicherweise bekannt vor, denn im Wesentlichen handelt es sich genau um die beiden zusätzlichen Themes aus der Developer Edition, mit dem Unterschied, dass die Wahl des Farbschemas nicht länger an die Entwicklerwerkzeuge gekoppelt ist, sondern das helle und das dunkle Theme jeweils einzeln im Add-on Manager zur Verfügung stehen. Ein Add-on, um diese Themes in der Beta- oder finalen Version von Firefox verfügbar zu machen, ist damit auch nicht länger notwendig.

Der Vorteil der kompakten Themes ist, dass diese weniger Platz in der Höhe benötigen und so mehr Platz für Webseiten zur Verfügung steht. Dies macht sich vor allem bei kleinen Bildschirmen bezahlt. Und wer dunkle Programmoberflächen bevorzugt – was nicht wenige tun -, findet damit bereits im Standard-Umfang von Firefox ein dunkles Firefox-Theme.

Themes Firefox 53
Themes Firefox 53
Themes Firefox 53

Die kompakten Themes können auch über Menü → Anpassen ausgewählt werden. Die Liste dort beworbener Lightweight Themes wird an dieser Stelle aufgrund der zusätzlichen Auswahl zum Ausgleich von fünf auf drei reduziert werden.

Themes Firefox 53

Neue Theming-API, basierend auf WebExtensions

Firefox kennt derzeit zwei Arten von Themes: Lightweight Themes, oder kurz auch einfach nur Themes, welche nur eine Textur über die Browseroberfläche legen und zwei Farben ändern, sowie die komplexen Themes, welche auch als vollständige Themes bezeichnet werden und jeden Aspekt der Firefox-Oberfläche ändern können.

Während die Lightweight Themes simpel sind und keine technische Hürde darstellen, sieht die Situation mit den vollständigen Themes ganz anders aus. Gerade für die Entwickler von Themes ist die derzeitige Form der vollständigen Themes eine Hürde, da die Erstellung mit sehr hohem Aufwand verbunden ist. Und die immer schneller werdende Entwicklung von Firefox macht es auch immer schwieriger für die Theme-Ersteller, überhaupt noch Schritt zu halten und ihre Themes immer wieder anzupassen. Neue Theme-Ersteller haben es aufgrund vieler spezieller Mozilla-Eigenschaften (XUL) und verhältnismäßig wenig Dokumentation schwer, den Einstieg zu finden. Dazu kommt, dass Mozilla langfristig von XUL Abstand nehmen möchte. Der Umbau einzelner Teile von Firefox, die bisher in XUL geschrieben waren, mit Webtechnologie hat bereits begonnen und macht vor allem in den Entwickler-Werkzeugen sichtbare Fortschritte.

In Zukunft soll es nur noch eine Theming-API geben. Diese wird weit mächtiger sein als das, was bisher mit Lightweight Themes möglich war, aber auch deutlich weniger können, was mit heutigen vollständigen Themes möglich ist.

Dies muss aber nicht unbedingt ein Nachteil sein, wenn dies in einer deutlichen Vereinfachung für die Entwickler resultiert und dadurch unter Umständen sogar viele neue Themes hervorgehen werden. Denn Tatsache ist, dass heute so gut wie keine neuen vollständigen Themes mehr entstehen und einige ehemals populäre Themes nicht mehr gepflegt werden, was vor allem an den Schwierigkeiten des derzeitigen Systems für vollständige Themes liegt.

Die neue Theming-API basiert auf den sogenannten WebExtensions, der neuen Erweiterungs-Schnittstelle, welche Mozilla ab Firefox 57 ausschließlich unterstützen wird.

Im vergangenen Monat hat Mozilla das Prototyping einer neuen Theming-API in einem separaten Entwicklungszweig von Firefox beendet. Vor wenigen Tagen wurde schließlich die Hauptentwicklung der neuen Theming-API aufgenommen. Diese wird seit der heutigen Nightly-Version hinter dem about:config-Schalter extensions.webextensions.themes.enabled entwickelt.

Das folgende Video zeigt den Prototyp der neuen Theming-API und was damit möglich sein könnte.

Link zum Original-Video

Photon: Neues Standard-Design von Firefox

Und schließlich gibt es noch das Projekt Photon. Der letzte große optische Umbau von Firefox liegt nun knapp drei Jahre zurück und wurde damals unter dem Projektnamen Australis entwickelt. Photon soll ein für dieses Jahr geplantes Update des Standard-Themes werden und ist Teil der übergeordneten Quantum-Initiative und deren erster Veröffentlichung. Zum Photon-Projekt sind bisher noch keine Details bekannt. So kann auch noch nicht gesagt werden, ob der Anwender hier Detail-Verbesserungen des bisherigen Standard-Designs oder gar größere Änderungen zu erwarten hat.

Der Beitrag Firefox: 2017 stehen Themes im Vordergrund erschien zuerst auf soeren-hentzschel.at.

Kurz notiert: gestern Abend wurde Debian 8.7 veröffentlicht. Neuerungen gibt es wenige, dieser kleinere Release stützt sich eher auf Security-Updates. Alte Debian 8-Installationsmedien werden selbstverständlich weiterhin funktionieren, da bei einer Installation meist die neusten Versionen der jeweiligen Pakete installiert werden.

Das Changelog sowie die Mitteilung vom Debian-Team befinden sich hier: https://www.debian.org/News/2017/20170114https://lists.debian.org/debian-announce/2017/msg00000.html