ubuntuusers.de

8. Mai 2018

Ich bin ein großer Freund vom Datenschutz, leider unterstützt Hugo nur disqus, was alles andere als freundlich zum Datenschutz ist. Also gab es die letzten Monate nie eine Kommentar Funktion, das hat sich jetzt geändert.

Ich bin durch Zufall auf den Artikel von Don Williamson gestoßen, der es mir erlaubt eine Kommentar Funktion für meine Artikel durch Github anzubieten.

Konfiguration

Als erstes legen wir eine Datei comments.html im Ordner themes/THEME_NAME/layouts/partials/ mit folgenden Inhalt an:

<div id="gh-comments">
          <h2>Kommentare</h2>
              <div id="gh-comments-list"></div>
                  <a href="javascript:void(0)" id="gh-load-comments" class="btn" style="display:none">Load more comments</a>
</div>

   <script type="text/javascript" data-ghid="{{ $.Params.ghcommentid }}" src="{{ .Site.BaseURL }}js/github-comments.js"></script>

Als nächstes brauchen wir jetzt noch die JS Datei, die für uns die ganze Arbeit macht themes/THEME_NAME/static/js/github-comments.js mit folgenden Inhalt:

// use of ajax vs getJSON for headers use to get markdown (body vs body_htmml)
// todo: pages, configure issue url, open in new window?
//

var this_js_script = $('script[src*=github-comments]');


var ghid = this_js_script.attr('data-ghid');   
if (typeof ghid === "undefined" ) {
   var ghid = '0';
}

DoGithubComments(ghid);

var CurrentPage = 0;

function ParseLinkHeader(link)
{
    var entries = link.split(",");
    var links = { };
    for (var i in entries)
    {
        var entry = entries[i];
        var link = { };
        link.name = entry.match(/rel=\"([^\"]*)/)[1];
        link.url = entry.match(/<([^>]*)/)[1];
        link.page = entry.match(/page=(\d+).*$/)[1];
        links[link.name] = link;
    }
    return links;
}

function DoGithubComments(comment_id, page_id)
{
    var repo_name = "beli3ver/malte-kiefer.de";

    if (page_id === undefined)
        page_id = 1;

    var api_url = "https://api.github.com/repos/" + repo_name;
    var api_issue_url = api_url + "/issues/" + comment_id;
    var api_comments_url = api_url + "/issues/" + comment_id + "/comments" + "?page=" + page_id;

    var url = "https://github.com/beli3ver/malte-kiefer.de/issues/" + comment_id;

    $(document).ready(function ()
    {
        $.getJSON(api_issue_url, function(data) {
            NbComments = data.comments;
        });

        $.ajax(api_comments_url, {
            headers: {Accept: "application/vnd.github.v3.html+json"},
            dataType: "json",
            success: function(comments, textStatus, jqXHR) {

                // Add post button to first page
                if (page_id == 1)
                    $("#gh-comments-list").append("<a href='" + url + "#new_comment_field' rel='nofollow' class='btn'>Füge eine Kommentar hinzu</a>");

                // Individual comments
                $.each(comments, function(i, comment) {

                    var date = new Date(comment.created_at);

                    var t = "<div id='gh-comment'>";
                    t += "<img src='" + comment.user.avatar_url + "' width='24px'>";
                    t += "<b><a href='" + comment.user.html_url + "'>" + comment.user.login + "</a></b>";
                    t += " posted at ";
                    t += "<em>" + date.toUTCString() + "</em>";
                    t += "<div id='gh-comment-hr'></div>";
                    t += comment.body_html;
                    t += "</div>";
                    $("#gh-comments-list").append(t);
                });

                // Setup comments button if there are more pages to display
                var links = ParseLinkHeader(jqXHR.getResponseHeader("Link"));
                if ("next" in links)
                {
                    $("#gh-load-comments").attr("onclick", "DoGithubComments(" + comment_id + "," + (page_id + 1) + ");");
                    $("#gh-load-comments").show();
                }
                else
                {
                    $("#gh-load-comments").hide();
                }
            },
            error: function() {
                $("#gh-comments-list").append("Kommentarfunktion für diesen Beitrag nicht aktiviert!");
            }
        });
    });
}

Jetzt müssen die Links in der Datei angepasst werden. Ihr müsst eine eigne Repo anlegen bei Github und hier in der Datei anpassen. Achtung: Wir brauchen auch jQuery!. jQuery sollte umbedingt im <head></head> geladen werden.

Zum Schluss noch das Template für die Beitragsdatei anpassen (themes/THEME_NAME/layouts/_default/single.html) und den folgenden Teil for dem Aufruf des <footer></footer> Tags einfügen:

{{ partial "comments.html" . }}

Um jetzt die Kommentarfunktion zu nutzen, ein entsprechendes issue bei Github eröffnen, die ID merken. Wenn ihr dann einen neuen Beitrag erstellt, müsst ihr vor den “—” folgendes einfügen:

ghcommentid: ID

Und das wars, nun habt ihr und ich eine Kommentarfunktion.

CSP

Damit ihr diese Funktion mit CSP nutzen könnt, müssen folgende Einstellungen gesetzt sein:

img-src 'self' https://*.githubusercontent.com;
connect-src 'self' https://*.github.com

Foto: © Vladislav Kochelaevs / Fotolia.com

Der Desktop KDE Plasma hat sich langsam konsolidiert und gewinnt langsam deutlichen Mehrwert gegenüber der vorangegangenen Version, sowie konkurrierenden Desktopumgebungen. Erstmals in Version 5.11 lieferte man ein integriertes Verschlüsselungswerkzeug mit, genannt Plasma Vault. Dieses eignet sich zwar auch für lokale Ordner, ist aber insbesondere für die Verschlüsselung von Clouddateien gedacht.

Hierbei erfindet man das Rad nicht neu, sondern nutzt bereits bestehende Backends. Plasma Vault kann sowohl EncFS, als auch CryFS zur Verschlüsselung verwenden. Mit der Veröffentlichung von Plasma 5.12 änderte man  die Standardeinstellung auf das noch relativ junge CryFS.

Beide Verschlüsselungsmethoden arbeiten auf Dateibasis, weshalb sie sich gut für Cloudspeicher eignen. CryFS ist noch relativ jung und hat bisher keinen offiziellen Audit erhalten, worauf bei der Einrichtung auch hingewiesen wird. EncFS hat jedoch bekannte Sicherheitslücken und die Entwicklung ist diesbezüglich alles andere als transparent (siehe: (In)Transparenz von Open Source Entwicklung - Das Beispiel EncFS). Die Entscheidung zugunsten von CryFS ist deshalb nachvollziehbar.

Nachteil der CryFS-Lösung ist jedoch die Fixierung auf Linux und mit Abstrichen macOS. Eine Implementierung für Windows oder mobile Betriebssysteme fehlt bisher völlig. Wenn man sich also für eine CryFS-Verschlüsselung entscheidet sollte man sicherstellen, dass man in einem homogenen Linux-Ökosystem unterwegs ist. Plasma ist jedoch nicht zwingend erforderlich, da sich CryFS auch auf der Kommandozeile bedienen lässt.

Einrichtung

Installation

Einige Distributionen wie Kubuntu liefern Plasma Vault bereits standardmäßig aus, bei anderen muss dieses nachinstalliert werden. Es ist jedoch bei allen großen Distributionen wie Debian, openSUSE oder Arch Linux in den offiziellen Paketquellen und lässt sich daher problemlos nachinstallieren. Je nach Abhängigkeiten ist es ggf. erforderlich die notwendigen Backends CryFS oder EncFS zusätzlich zu installieren.

Vault erstellen

Ist Plasma Vault installiert, befindet sich im Systemabschnitt der Kontrollleiste ein Schlosssymbol.

Ruft man dieses auf wird einem prominent angeboten einen neuen Tresor anzulegen. Die Einrichtungsroutine fragt zuerst den Namen des neuen Speichers ab.

Hier kann man auch das Backend ändern. Wie bereits geschrieben empfiehlt Plasma Vault CryFS. Wählt man den Typ zeigt Plasma Vault einen spezifischen Hinweistext. Bei EncFS erfolgt eine Information zu den Sicherheitsproblemen, bei CryFS zum fehlenden Audit. Diese transparente Informationspolitik ist definitiv begrüßenswert.

Anschließend besteht die Möglichkeit den Verschlüsselungstyp näher zu spezifizieren.

Ohne triftigen Grund sollte man bei der Standardverschlüsselung bleiben. Auf manchen Systemen sind jedoch andere Verschlüsselungsmethoden deutlich schneller, weshalb es sinnvoll sein kann, dies zu überprüfen. Genauere Informationen liefert der folgende Befehl:

$ cryptsetup benchmark

Die Auswahl der Pfade erfolgt dem bekannten Prinzip aus Mountpoint und Ordner für die verschlüsselten Dateien. Letztere muss natürlich im Synchronisationsordner des Cloudspeichers abgelegt sein. Standardmäßig legt Plasma Vault diesen unterhalb von .local/share ab, was einen lokalen Verschlüsselungsordner erzeugen würde.

Das somit erzeugte Tresor ist anschließend automatisch eingebunden. Er kann einfach über das Plasma-Applet verwaltet werden, da ähnlich wie das Applet für Wechselmedien funktioniert.

In Dolphin befindet sich nun im Homeverzeichnis ein Ordner Vaults, in dem eingebundene Tresore als schwarzer Ordner mit Schloss visualisiert werden.

Fazit

Plasma Vault funktioniert einfach und fehlerfrei. Es ermöglicht eine einfache Verschlüsselung von Cloudspeicherordnern und motiviert hoffentlich mehr Anwender ihre Dateien nicht unverschlüsselt hochzuladen. Die Sicherheitsprobleme bzw. mangele Interoperabilität der Backends kann man den Plasma-Entwicklern nicht ankreiden, sondern verweist auf hier bestehende Probleme.

"

Ich bin ein großer Freund vom Datenschutz, leider unterstützt Hugo nur disqus, was alles andere als freundlich zum Datenschutz ist. Also gab es die letzten Monate nie eine Kommentar Funktion, das hat sich jetzt geändert.

Ich bin durch Zufall auf den Artikel von Don Williamson gestoßen, der es mir erlaubt eine Kommentar Funktion für meine Artikel durch Github anzubieten.

Konfiguration

Als erstes legen wir eine Datei comments.html im Ordner themes/THEME_NAME/layouts/partials/ mit folgenden Inhalt an:

<div id="gh-comments">
          <h2>Kommentare</h2>
              <div id="gh-comments-list"></div>
                  <a href="javascript:void(0)" id="gh-load-comments" class="btn" style="display:none">Load more comments</a>
</div>

   <script type="text/javascript" data-ghid="{{ $.Params.ghcommentid }}" src="{{ .Site.BaseURL }}js/github-comments.js"></script>

Als nächstes brauchen wir jetzt noch die JS Datei, die für uns die ganze Arbeit macht themes/THEME_NAME/static/js/github-comments.js mit folgenden Inhalt:

// use of ajax vs getJSON for headers use to get markdown (body vs body_htmml)
// todo: pages, configure issue url, open in new window?
//

var this_js_script = $('script[src*=github-comments]');


var ghid = this_js_script.attr('data-ghid');   
if (typeof ghid === "undefined" ) {
   var ghid = '0';
}

DoGithubComments(ghid);

var CurrentPage = 0;

function ParseLinkHeader(link)
{
    var entries = link.split(",");
    var links = { };
    for (var i in entries)
    {
        var entry = entries[i];
        var link = { };
        link.name = entry.match(/rel=\"([^\"]*)/)[1];
        link.url = entry.match(/<([^>]*)/)[1];
        link.page = entry.match(/page=(\d+).*$/)[1];
        links[link.name] = link;
    }
    return links;
}

function DoGithubComments(comment_id, page_id)
{
    var repo_name = "beli3ver/malte-kiefer.de";

    if (page_id === undefined)
        page_id = 1;

    var api_url = "https://api.github.com/repos/" + repo_name;
    var api_issue_url = api_url + "/issues/" + comment_id;
    var api_comments_url = api_url + "/issues/" + comment_id + "/comments" + "?page=" + page_id;

    var url = "https://github.com/beli3ver/malte-kiefer.de/issues/" + comment_id;

    $(document).ready(function ()
    {
        $.getJSON(api_issue_url, function(data) {
            NbComments = data.comments;
        });

        $.ajax(api_comments_url, {
            headers: {Accept: "application/vnd.github.v3.html+json"},
            dataType: "json",
            success: function(comments, textStatus, jqXHR) {

                // Add post button to first page
                if (page_id == 1)
                    $("#gh-comments-list").append("<a href='" + url + "#new_comment_field' rel='nofollow' class='btn'>Füge eine Kommentar hinzu</a>");

                // Individual comments
                $.each(comments, function(i, comment) {

                    var date = new Date(comment.created_at);

                    var t = "<div id='gh-comment'>";
                    t += "<img src='" + comment.user.avatar_url + "' width='24px'>";
                    t += "<b><a href='" + comment.user.html_url + "'>" + comment.user.login + "</a></b>";
                    t += " posted at ";
                    t += "<em>" + date.toUTCString() + "</em>";
                    t += "<div id='gh-comment-hr'></div>";
                    t += comment.body_html;
                    t += "</div>";
                    $("#gh-comments-list").append(t);
                });

                // Setup comments button if there are more pages to display
                var links = ParseLinkHeader(jqXHR.getResponseHeader("Link"));
                if ("next" in links)
                {
                    $("#gh-load-comments").attr("onclick", "DoGithubComments(" + comment_id + "," + (page_id + 1) + ");");
                    $("#gh-load-comments").show();
                }
                else
                {
                    $("#gh-load-comments").hide();
                }
            },
            error: function() {
                $("#gh-comments-list").append("Kommentarfunktion für diesen Beitrag nicht aktiviert!");
            }
        });
    });
}

Jetzt müssen die Links in der Datei angepasst werden. Ihr müsst eine eigne Repo anlegen bei Github und hier in der Datei anpassen. Achtung: Wir brauchen auch jQuery!. jQuery sollte umbedingt im <head></head> geladen werden.

Zum Schluss noch das Template für die Beitragsdatei anpassen (themes/THEME_NAME/layouts/_default/single.html) und den folgenden Teil for dem Aufruf des <footer></footer> Tags einfügen:

{{ partial "comments.html" . }}

Um jetzt die Kommentarfunktion zu nutzen, ein entsprechendes issue bei Github eröffnen, die ID merken. Wenn ihr dann einen neuen Beitrag erstellt, müsst ihr vor den "---" folgendes einfügen:

ghcommentid: ID

Und das wars, nun habt ihr und ich eine Kommentarfunktion.

CSP

Damit ihr diese Funktion mit CSP nutzen könnt, müssen folgende Einstellungen gesetzt sein:

img-src 'self' https://*.githubusercontent.com;
connect-src 'self' https://*.github.com

7. Mai 2018

Mozilla wird am Mittwoch Firefox 60 veröffentlichen. Firefox 60 wird gleichzeitig die neue Basis für Firefox ESR sein, die Firefox-Version mit Langzeitunterstützung. Während Firefox 60 und Firefox ESR 60 grundsätzlich identisch sind, gibt es doch ein paar wichtige Unterschiede zwischen beiden Versionen.

Mozilla wird am 9. Mai 2018 Firefox 60 und Firefox ESR 60 veröffentlichen. Nutzer von Firefox ESR 52 haben ab dann noch 17 Wochen Zeit, ehe sie mit Erscheinen von Firefox 62 und Firefox ESR 60.2 am 5. September 2018 automatisch auf Firefox ESR 60 migriert werden. Wie schon Firefox ESR 52 unterscheidet sich auch Firefox ESR 60 in ein paar Aspekten von seinem Mainstream-Pendant.

Firefox ESR 60: standardmäßig keine Service Workers

Service Workers gehören zweifelsohne zu den Webstandards, welche in Zukunft aus vielen modernen Webapplikationen nicht mehr wegzudenken sein werden. Firefox unterstützt Service Workers seit Version 44. Schon in Firefox ESR 45 waren Service Workers aufgrund damals zu erwartender Spezifikations- und Implementierungsänderungen standardmäßig deaktiviert. Auch in Firefox ESR 52 waren Service Workers standardmäßig deaktiviert, wegen andauernden Änderungen unter der Haube zur vollständigungen Unterstützung mehrerer Content-Prozesse, was es schwierig machen würde, Fixes für Firefox ESR zurück zu portieren. Aus dem gleichen Grund werden Service Workers auch in Firefox ESR 60 standardmäßig deaktiviert sein.

Zur Aktivierung in Firefox ESR 60 muss der folgende Schalter über about:config auf true geschaltet werden:

dom.serviceWorkers.enabled

Firefox ESR 60: standardmäßig keine Push-Benachrichtigungen

Ebenfalls werden Push-Benachrichtigungen in Firefox ESR 60 standardmäßig deaktiviert sein, da diese Service Workers als technische Voraussetzung haben.

Zur Aktivierung in Firefox ESR 60 muss der folgende Schalter über about:config auf true geschaltet werden:

dom.push.enabled

Nur in Firefox ESR 60: zusätzliche Enterprise Policies

Mit Firefox 60 liefert Mozilla erstmals seine sogenannte Enterprise Policy Engine aus. Damit ist es für Systemadministratoren möglich, Firefox für die Verteilung im Unternehmen vorzukonfigurieren, wofür bis einschließlich Firefox ESR 52 gerne der sogenannte CCK2 Wizard benutzt worden ist, der allerdings mit Firefox 57 und höher nicht kompatibel ist.

Firefox ESR 60 wird zusätzliche Enterprise Policies unterstützen, welche in der Mainstream-Version von Firefox nicht funktionieren.

Tipp: Die Firefox-Erweiterung Enterprise Policy Generator, welche ich voraussichtlich in dieser Woche veröffentlichen werde, erlaubt ein einfaches Zusammenklicken aller möglichen Enterprise Policies und wird außerdem diejenigen Policies besonders kennzeichnen, welche ausschließlich in Firefox ESR funktionieren.

Firefox Enterprise Policy Generator Vorschau

Nur in Firefox ESR 60: deaktivierbare Signaturpflicht für Add-ons

Zum Schutz seiner Nutzer hat Mozilla eine Signaturpflicht für Add-ons in Firefox eingeführt, welche seit Firefox 43 standardmäßig aktiviert ist. Diese kann nur in Nightly-Builds sowie in der Developer Edition von Firefox deaktiviert werden, nicht in Beta- oder finalen Versionen. Die ESR-Version von Firefox 60 erlaubt auch in der finalen Ausführung die Deaktivierung der Signaturpflicht.

Zur Deaktivierung in Firefox ESR 60 muss der folgende Schalter über about:config auf false geschaltet werden:

xpinstall.signatures.required

Achtung: Es ist aus Sicherheitsgründen nicht empfohlen, die Signaturpflicht für Erweiterungen zu deaktivieren. Wer seine Erweiterungen ausschließlich über addons.mozilla.org bezieht, findet außerdem in der Regel sowieso ausschließlich signierte Erweiterungen vor.

Folgende Unterschiede aus Firefox ESR 52 existieren nicht mehr

Folgende Unterschiede existierten noch zwischen Firefox 52 und Firefox ESR 52, werden aber nicht mehr zwischen Firefox 60 und Firefox ESR 60 existieren:

Multiprozess-Architektur: Für die Auslieferung der Multiprozess-Architektur gab es in Firefox ESR 52 strengere Kriterien als in der Mainstream-Version von Firefox 52, was dazu führte, dass die Multiprozess-Architektur in der ESR-Version mit einer höheren Wahrscheinlichkeit deaktiviert war. In Firefox ESR 60 besteht diesbezüglich kein Unterschied zu Firefox 60.

NPAPI-Plugins: Während in der Mainstream-Version von Firefox 52 der Adobe Flash Player als einziges NPAPI-Plugin unterstützt worden ist, konnten in Firefox ESR 52 auch andere NPAPI-Plugins wie Microsoft Silverlight und Oracle Java genutzt werden. Firefox ESR 60 unterstützt wie die Mainstream-Version nur noch den Adobe Flash Player als einziges NPAPI-Plugin.

WebAssembly (wasm): WebAssembly, oder kurz: wasm, ist ein neues Binärformat für das Web. Ähnlich wie bei Mozillas asm.js oder Googles PNaCl handelt es sich dabei um das Resultat kompilierten Codes und soll die Performance von Webanwendungen auf eine neue Ebene heben. In Firefox ESR 52 war WebAssembly standardmäßig deaktiviert, in Firefox ESR 60 wird WebAssembly standardmäßig aktiviert sein.

Windows XP: Nutzer von Windows XP und Windows Vista erhalten bis zum Lebensende von Firefox ESR 52 noch Sicherheits-Aktualisierungen. Ein Update auf Firefox 60 respektive Firefox ESR 60 wird es für entsprechende Nutzer nicht mehr geben.

Der Beitrag Alle Unterschiede zwischen Firefox 60 und Firefox ESR 60 erschien zuerst auf soeren-hentzschel.at.

Im folgenden Artikel möchte ich erklären, wie man eine Webserver Umgebung mit PHP-FPM und Let’s Encrypt Zertifikaten mit dem Webserver Lighttpd (lighty) umsetzen kann. Die folgende Konfiguration führt dazu, dass ihr bei folgenden Tests, eine A(+) bekommt:

Hinweis: Ein natürlicher Menschenverstand wird vorausgesetzt, bitte nicht einfach blind kopieren!

Installation

Als erstes installieren wir die benötigt Software:

apt install lighttpd php-fpm certbot

Konfiguration

lighttpd - PHP-FPM

Im folgenden werden wir lighttpd konfigurieren. Als erstes sorgen wir dafür das lighttpd mit PHP-FPM umgehen kann, dazu gehen wir in den Ordner /etc/lighttpd/conf-available/.

Dort werden wir jetzt die Datei 15-fastcgi-php.conf bearbeiten, und folgenden Inhalt einfügen:

# -*- depends: fastcgi -*-
# /usr/share/doc/lighttpd/fastcgi.txt.gz
# http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs:ConfigurationOptions#mod_fastcgi-fastcgi

## Start an FastCGI server for php (needs the php5-cgi package)
fastcgi.server += ( ".php" =>
        ((
                "socket" => "/var/run/php/php7.2-fpm.sock",
                "broken-scriptfilename" => "enable"
        ))
)

Umbedingt den Socket Pfad kontrollieren! Jetzt sagen wir lighttpd er soll das Modul laden:

lighttpd-enable-mod fastcgi
lighttpd-enable-mod fastcgi-php
service lighttpd force-reload

Jetzt kann lighttpd mit PHP Dateien umgehen.

lighttpd

Im folgenden werden wir lighttpd konfigurieren. Dazu bearbeiten wir die Datei /etc/lighttpd/lighttpd.conf und fügen folgenden Inhalt hinzu:

server.modules = (
        "mod_access",
        "mod_alias",
        "mod_compress",
        "mod_redirect",
        )
#default webseite
server.document-root        = "/var/www/html/kiefer-networks.de/"
server.upload-dirs          = ( "/var/cache/lighttpd/uploads" )
server.errorlog             = "/var/log/lighttpd/error.log"
server.pid-file             = "/var/run/lighttpd.pid"
server.username             = "www-data"
server.groupname            = "www-data"
server.port                 = 80
#Server Tag ist der Name der angezeigt wird beim Abtasten des Servers (Nginx v.234)
server.tag                  = "Mein Server"


index-file.names            = ( "index.php", "index.html", "index.lighttpd.html" )
#Zugriff auf folgende Dateien untersagen
url.access-deny             = ( "~", ".inc" )
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )

compress.cache-dir          = "/var/cache/lighttpd/compress/"
compress.filetype           = ( "application/javascript", "text/css", "text/html", "text/plain" )

# default listening port for IPv6 falls back to the IPv4 port
include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port
include_shell "/usr/share/lighttpd/create-mime.assign.pl"
include_shell "/usr/share/lighttpd/include-conf-enabled.pl"

#Wir erlauben nur das die HTTP Requests Methoden GET & POST erlaubt sind

$HTTP["request-method"] !~ "^(GET|POST)" {
    url.access-deny = ("")
}

#Setzten der entsprechenden HTTP Headers, Achtung CSP anpassen

server.modules += ( "mod_setenv" )
$HTTP["scheme"] == "https" {
    setenv.add-response-header  = (
            "Content-Security-Policy"   => "default-src 'self'; script-src 'self'; object-src 'none'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self'; media-src 'self'; frame-src https://*.openstreetmap.org https://*.google.com; font-src https://fonts.googleapis.com; connect-src 'none'",
            "Strict-Transport-Security" => "max-age=15768000; includeSubDomains; preload",
            "X-Content-Type-Options" => "nosniff",
            "X-Frame-Options" => "DENY",
            "X-XSS-Protection" => "1; mode=block"
            )
}

#Umleiten von HTTP zu HTTPS

$HTTP["scheme"] == "http" {
    $HTTP["host"] =~ ".*" {
        url.redirect = (".*" => "https://%0$0")
    }
}

#Multi Webseiten Konfiguration

$HTTP["host"] =~ "(^|\.)example\.de$" {
    	server_name = "example.de"
        server.document-root = "/var/www/html/example.de" 
        server.errorlog = "/var/log/lighttpd/ex_de_error.log"	
}

$HTTP["host"] =~ "(^|\.)example\.com$" {
    	server_name = "example.com"
        server.document-root = "/var/www/html/example.com" 
        server.errorlog = "/var/log/lighttpd/ex_com_error.log"	
}

lighttpd SSL Konfiguration

Jetzt werden wir noch die SSL Konfiguration anpassen. Dazu bearbeiten wir die Datei /etc/lighttpd/conf-available/10-ssl.conf. Wir passen den Inhalt wir folgt an:

$SERVER["socket"] == ":443" {
    protocol     = "https://"
        ssl.engine   = "enable"
        ssl.disable-client-renegotiation = "enable"
        ssl.pemfile = "/etc/lighttpd/ssl/example.de.pem" 
        ssl.ca-file = "/etc/lighttpd/ssl/fullchain.pem"

        ssl.ec-curve              = "secp384r1"

        setenv.add-environment = (
                "HTTPS" => "on"
                )
        ssl.use-sslv2 = "disable"
        ssl.use-sslv3 = "disable"
        ssl.honor-cipher-order    = "enable"
        ssl.cipher-list           = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256"

        $HTTP["host"] =~ "(^|\.)example\.de$" {
            ssl.pemfile = "/etc/lighttpd/ssl/example.de.pem"
            ssl.ca-file = "/etc/lighttpd/ssl/fullchain.pem"
        }


    	$HTTP["host"] =~ "(^|\.)example\.com$" {
        	ssl.pemfile = "/etc/lighttpd/ssl/example.com.pem"
            ssl.ca-file = "/etc/lighttpd/ssl/fullchain.pem"
    	}
}

Dazu erstellen wir noch den folgenden Ordner

mkdir /etc/lighttpd/ssl/

Jetzt noch das SSL Modul aktivieren

lighttpd-enable-mod ssl
service lighttpd restart

Let’s Encrypt

Bei lighttpd gibt es eine Besonderheit bei den Zertifikaten, so muss der Private Schlüssel und das Zertifikate in einer Datei sein und das CA immer als Referenz mit angebenen sein. Damit wir das nicht für jede Datei einzeln machen müssen, werden wird ein fertiges Script nehmen, was sich auch darum kümmert, die Zertifikate aktuell zu halten.

Dazu wechseln wir nach /opt. Dann klonen wir folgenden Repo:

git clone https://github.com/galeone/letsencrypt-lighttpd.git

Wechselt in den neuen Ordner letsencrypt-lighttpd. Als erstes bearbeiten wir die Datei letsencrypt-lighttpd.service und passen den ExecStart an nach /opt/letsencrypt-lighttpd/renew.sh.

ExecStart=/opt/letsencrypt-lighttpd/renew.sh

Dann kopieren die Service Dateien und starten den Dienst:

cp letsencrypt-lighttpd.* /etc/systemd/system/
systemctl enable letsencrypt-lighttpd.timer

Jetzt der “schwierige” Teil, wir passen noch renew.sh an:

#!/usr/bin/env bash 
set -eu

#Domain sudomain part (mail.example.de => mail)
domain_subdomains=( \
#domain     sub sub sub
"example.de w ww www" \
"example.com w ww www" \
)
email=mail@example.de
w_root=/var/www/html/ #Speicherort der Webseiten
user=root
group=root

# end configuration

if [ "$EUID" -ne 0 ]; then
    echo  "Please run as root"
    exit 1
fi

for domain_set_string in "${domain_subdomains[@]}"; do
    domain_set=(${domain_set_string// / })
    domain=${domain_set[0]}
    unset domain_set[0]

    all_subdomains="-d $domain"
    if [ ${#domain_set[@]} -gt 0 ]; then
        for sub_domain in "${domain_set[@]}"; do
            all_subdomains="$all_subdomains -d $sub_domain.$domain"
        done
    fi

    /usr/bin/certbot certonly --agree-tos --renew-by-default \
        --rsa-key-size 4096 --email $email --webroot -w $w_root$domain \
        $all_subdomains
    cat /etc/letsencrypt/live/$domain/privkey.pem \
        /etc/letsencrypt/live/$domain/cert.pem \
        > /etc/lighttpd/ssl/$domain.pem
    cp /etc/letsencrypt/live/$domain/fullchain.pem \
       /etc/lighttpd/ssl/
    chown -R $user:$group /etc/lighttpd/
	chmod 600 /etc/lighttpd/*.pem
done

Hinweis: Die Webseiten müssen im Ordner /var/www/html/ gespeichert werden, im Format der angegebenen Domain: /var/www/html/example.de

Jetzt starten wir die Dienste neu:

service php7.2-fpm restart
service lighttpd restart

Dann lassen wir uns noch die Zertifikate austellen

bash /opt/letsencrypt-lighttpd/renew.sh

Fazit

Der Lighttpd ist ein leistungsstarker Server, der wunderbar ein Ersatz für nginx und Apache sein kann.

Im heutigen Beitrag aus der Kategorie Wochenend-Projekte geht es darum, wie man mit Hilfe eines Reverse-SSH-Tunnels ein Offsite-Backup für die heimische Datensammlung realisieren kann. Der Beitrag soll mir als Dokumentation und euch als Anregung für ähnliche Projekte dienen.

Anwendungsfall (Use Case)

In meinem Heimnetzwerk gibt es ein NAS, welches der Familie als allgemeines Datengrab dient. Lagen hier anfangs nur Datensicherungen anderer Geräte, verwalten wir heute, neben anderen Daten, unsere Familien- und Urlaubsfotos auf diesem Gerät. Es existiert eine lokale Datensicherung dieser Daten, die vor versehentlichem Löschen schützt.

Nun sind uns einige dieser Daten so wichtig, dass wir sie auch gern gegen Verlust durch z.B. Feuer oder Diebstahl schützen möchten. Dazu möchte ich die betreffenden Daten gern außerhalb der eigenen vier Wände an einem anderen Standort sichern. Diese Form der Datensicherung bezeichne ich im Folgenden auch als Offsite-Backup.

Anforderungen

An das Offsite-Backup stelle ich folgende Anforderungen:

  1. Die Datenübertragung erfolgt über gesicherte Verbindungen
  2. Die Daten werden in einem Format gespeichert, welches das Lesen ohne Abhängigkeit zu bestimmten Programmen ermöglicht
  3. Die Datenübertragung soll manuell angestoßen werden und optional zeitgesteuert ausgeführt werden können
  4. Eine Wiederherstellung der Daten soll über den gleichen Kanal wie die Datensicherung möglich sein
  5. Die Daten sollen nicht bei einem kommerziellen Anbieter gespeichert werden
  6. Die Daten sollen nicht in einem Speicher abgelegt werden, der sich des unmittelbaren Zugriffs entzieht
  7. In den Routern der beteiligten Heimnetzwerke sollen keine eingehenden Portweiterleitungen konfiguriert werden müssen

Alles was ich benötige, um die obigen Anforderungen umzusetzen sind:

  1. Ein Raspberry Pi
  2. Eine externe USB-Festplatte zum Anschluss an den Pi
  3. Einen Linux-Root-Server im Internet
  4. Einen LAN-Port und Stromanschluss im Elternhaus

Zu meinem Glück sind all diese Dinge bereits vorhanden und ich muss nicht erst eine Einkaufstour unternehmen.

Die Lösung

In groben Zügen erklärt, sieht die Lösung wie folgt aus. An den Raspberry Pi wird eine USB-Festplatte angeschlossen, welche als Speicher für die zu sichernden Daten dient. Der Pi wird in meinem Elternhaus an das dortige Heimnetzwerk angeschlossen. Von dort ausgehend baut er einen Reverse-SSH-Tunnel zu meinem Linux-Server auf, welcher bei einem Hoster läuft und auf eingehende SSH-Verbindungen lauscht. So kann ich von dem Linux-Server aus auf den Pi zugreifen, ohne dass im DSL-Router in meinem Elternhaus eine Portweiterleitung eingerichtet werden muss. Darüber hinaus entfällt auch die Notwendigkeit, die Gegenstelle über die sich ändernde dynamische IP-Adresse auf dem Laufenden zu halten.

model of an offsite backup

SSH-Verbindungen über eine Vermittlungsstelle für ein Offsite-Backup

Nun kann ich von dem NAS aus meinem Heimnetzwerk eine SSH-Verbindung über den Linux-Server zum Raspberry Pi in meinem Elternhaus aufbauen und Daten dorthin übertragen. Auch in meinem Heimnetzwerk muss dazu keine Portweiterleitung geschaffen werden.

Konfiguration auf dem Pi

Auf dem Raspberry Pi habe ich das Betriebssystem Raspbian installiert. Anschließend habe ich ein SSH-Schlüsselpaar erstellt und den öffentlichen SSH-Schlüssel auf dem Linux-Server hinzugefügt, um ohne die Eingabe eines Passworts eine SSH-Verbindung herstellen zu können. Für die Verbindung verwende ich normale Linux-Benutzer ohne besondere Privilegien. Nun kann mit dem Befehl ssh -R 22222:localhost:22 user@Linux-Server ein Reverse-SSH-Tunnel zum Raspberry Pi aufgebaut werden. Der Reverse-SSH-Tunnel ermöglicht es, vom Linux-Server aus mit dem Befehl ssh -p22222 localhost eine Verbindung zum Raspberry Pi aufbauen zu können.

Damit der Reverse-SSH-Tunnel nach der Provider-Zwangstrennung automatisch wieder aufgebaut wird, habe ich auf dem Raspberry Pi folgende Service-Unit erstellt:

[Unit]
Description="Reverse ssh tunnel to proxy"
After=network.target

[Service]
User=pusemuckel
ExecStart=/usr/bin/ssh -NTi /home/pusemuckel/.ssh/id_rsa -o ServerAliveInterval=60 -R 22222:localhost:22 user@Linux-Server
RestartSec=73
Restart=always

[Install]
WantedBy=multi-user.target

Die Option RestartSec gibt an, dass bei einem Verbindungsabbruch 73 Sekunden gewartet wird, bevor ein erneuter Verbindungsversuch gestartet wird. Damit möchte ich dem DSL-Router Zeit für die Wiedereinwahl geben.

Konfiguration auf dem NAS

Auf dem NAS erstelle ich im HOME-Verzeichnis des Benutzers, welcher später die Datensicherung ausführen wird, die Datei ~/.ssh/config mit folgendem Inhalt, um auf einfache Weise eine SSH-Verbindung zum Raspberry Pi im entfernten Standort herstellen zu können.

Host raspi
        HostName localhost
        Port 22222
        ProxyCommand ssh -i ~/.ssh/nas_rsa -A -W %h:%p user@linux-server
        IdentityFile ~/.ssh/nas_rsa

ProxyCommand gibt an, dass der Linux-Server als Proxy bzw. Zwischenpunkt der Verbindung dient. In neueren SSH-Versionen kann man statt dessen auch die etwas einfacher zu handhabende Option JumpHost verwenden.

Neben der obigen Datei wurde auf dem NAS ein SSH-Schlüsselpaar erstellt, dessen öffentlicher Schlüssel auf dem Linux-Server und dem Raspberry Pi im entfernten Standort hinterlegt wurde. Dadurch ist für die Durchführung der Datensicherung keine Passworteingabe erforderlich. Da beide Endpunkte der Verbindung in vertrauenswürdigen Netzen liegen, halte ich diese Vorgehensweise für vertretbar.

Probleme

Leider läuft das Ganze noch nicht so rund und störungsarm, wie ich es mir wünsche. Bei der Zwangstrennung reißt die Verbindung ab, ohne dass der Raspberry Pi eine Chance hätte, den Socket auf dem Server zu schließen.

Da der verwendete Port noch auf dem Linux-Server gebunden ist, schlägt eine erneute Einwahl fehl. Erst wenn der Socket nach einem Timeout geschlossen wurde, ist eine erneute Wiederherstellung der Verbindung möglich.

Update 2018-05-21: Danke an Christian F., welcher mich auf die Optionen ClientAliveCountMax und ClientAliveInterval hingewiesen hat. Mit diesen Optionen kann der SSH-Server erkennen, dass die Verbindung zum Client abgerissen ist und den Socket schließen.

Der Standardwert für ClientAliveCountMax beträgt 3. Dabei handelt es sich um client alive messages, welche der Server zum Client sendet. Bleiben alle drei unbeantwortet, baut der Server die Verbindung ab und gibt den Socket frei. Den Wert für ClientAliveInterval habe ich auf 15 gesetzt. Er gibt an, dass nach 15 Sekunden Inaktivität eine client alive message vom Server an den Client gesendet wird, um zu überprüfen, ob der Client noch antwortet.

Antwortet der Client nicht, wird mit der obigen Konfiguration die Verbindung vom Server nach 45 Sekunden abgebaut und der Socket freigegeben. Der Client kann sich anschließend wieder neu verbinden. Auf dem Client habe ich den Parameter RestartSec auf 73 Sekunden gesetzt (einfach weil mir die Zahl so gut gefällt). Nach dem Abriss der Verbindung durch die Zwangstrennung wird der Tunnel nach 73 Sekunden wieder aufgebaut.

Fazit

Mit dieser kleinen Bastellösung kann ich meine Daten über einen gesicherten Kanal in einen entfernten Standort sichern. Das manuelle Offsite-Backup klappt bereits gut, wenn der SSH-Tunnel zwischen Linux-Server und Raspberry Pi steht.

Da das Problem mit der Zwangstrennung nun etwas entschärft werden konnte, steht auch einem zeitgesteuerten Backup grundsätzlich nichts mehr im Wege. Es bleibt lediglich das Restrisiko, dass sich der Zeitpunkt der Zwangstrennung ändert und diese dann das zeitgesteuerte Backup unterbricht. Mit diesem Risiko komme ich jedoch zurecht.

Bild von harshahars via Pixabay / Lizenz: CC0 Creative Commons

App Stores sind gegenwärtig das Mittel der Wahl um Programme zu verwalten. Populär gemacht hat sie Apple mit dem iPhone aber inzwischen gibt es kaum ein System, das ohne sie auskommt. iOS, Android, macOS, Windows - und Linux? Nun, Linux versucht sich auch seit Jahren daran - und scheitert immer wieder. Die Frage ist warum?

Eigentlich hatten alle Linux-Distributionen gute Startbedingungen. Im Gegensatz zu Windows oder macOS verwaltete man die Software schon immer in handlichen Paketen über eine Paketverwaltung. Das gebündelte App Store-Prinzip war zum greifen nah. Es fehlten lediglich Metadaten und eine Trennung in "richtige" Programme und Bibliotheken etc., die als Abhängigkeiten benötigt wurden. Hier ist man in den letzten Jahren auch deutlich voran gekommen. Mit AppStream gibt es eine zentrale Stelle, die Metadaten zusammen trägt und von allen großen Distributionen unterstützt wird.

Leider scheitert man in der Praxis. Nachdem Ubuntu Software erst lange dahin siechte und schließlich zugunsten von GNOME Software aufgegeben wurde, gibt es noch zwei Stores: Plasma Discover und GNOME Software. Beide können über Backends mit allen großen Paketverwaltungen umgehen und beherrschen experimentell auch Snaps und Flatpaks.

Beide Lösungen versagen aber regelmäßig in der Praxis. Mit kaum einem Werkzeug schafft es der normale Anwender sein System mit Problemen zu belasten, wie mit der Benutzung eines Stores. Entweder weil man aus versehen Snaps statt normalen Paketen installiert oder weil Paketabhängigkeiten nicht korrekt aufgelöst werden. Manche Fehler sind auch gar nicht reproduzierbar. Die Kritik an diesen Systemen findet sich in fast jedem größeren Testbericht zu Ubuntu 18.04.

Die Distributionen gegeben dieses Problem quasi selbst zu indem sie wie Kubuntu mit Muon, Debian/Ubuntu mit Synaptic oder SUSE mit YaST klassische Paketverwaltungen empfehlen um Probleme zu lösen.

Trotzdem geht der Trend Richtung Store-Prinzip, weil man erkannt hat, dass bisherige Paketverwaltungen zu unübersichtlich, behäbig und zur modernen Softwareverwaltung nicht mehr zeitgemäß sind. Beim Basissystem mag das noch anders aussehen, aber die meisten Linux-Distributionen nehmen hier keine Trennung vor. Anders als z. B. FreeBSD, macOS oder Windows.

Warum scheitert Linux derart dabei eine moderne Programmverwaltung zu implementieren? Fehlender Wille alte Zöpfe abzuschneiden? Fehlende Unterstützung durch die Supportcommunity? Oder sehen wir bereits die Abkehr der Distributoren vom Desktop? App Stores spielen im Server- und Enterprise-Markt naturgemäß keine Rolle.

"

Im folgenden Artikel möchte ich erklären, wie man eine Webserver Umgebung mit PHP-FPM und Let's Encrypt Zertifikaten mit dem Webserver Lighttpd (lighty) umsetzen kann. Die folgende Konfiguration führt dazu, dass ihr bei folgenden Tests, eine A(+) bekommt:

Hinweis: Ein natürlicher Menschenverstand wird vorausgesetzt, bitte nicht einfach blind kopieren!

Installation

Als erstes installieren wir die benötigt Software:

apt install lighttpd php-fpm certbot

Konfiguration

lighttpd - PHP-FPM

Im folgenden werden wir lighttpd konfigurieren. Als erstes sorgen wir dafür das lighttpd mit PHP-FPM umgehen kann, dazu gehen wir in den Ordner /etc/lighttpd/conf-available/.

Dort werden wir jetzt die Datei 15-fastcgi-php.conf bearbeiten, und folgenden Inhalt einfügen:

# -*- depends: fastcgi -*-
# /usr/share/doc/lighttpd/fastcgi.txt.gz
# http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs:ConfigurationOptions#mod_fastcgi-fastcgi

## Start an FastCGI server for php (needs the php5-cgi package)
fastcgi.server += ( ".php" =>
        ((
                "socket" => "/var/run/php/php7.2-fpm.sock",
                "broken-scriptfilename" => "enable"
        ))
)

Umbedingt den Socket Pfad kontrollieren! Jetzt sagen wir lighttpd er soll das Modul laden:

lighttpd-enable-mod fastcgi
lighttpd-enable-mod fastcgi-php
service lighttpd force-reload

Jetzt kann lighttpd mit PHP Dateien umgehen.

lighttpd

Im folgenden werden wir lighttpd konfigurieren. Dazu bearbeiten wir die Datei /etc/lighttpd/lighttpd.conf und fügen folgenden Inhalt hinzu:

server.modules = (
        "mod_access",
        "mod_alias",
        "mod_compress",
        "mod_redirect",
        )
#default webseite
server.document-root        = "/var/www/html/kiefer-networks.de/"
server.upload-dirs          = ( "/var/cache/lighttpd/uploads" )
server.errorlog             = "/var/log/lighttpd/error.log"
server.pid-file             = "/var/run/lighttpd.pid"
server.username             = "www-data"
server.groupname            = "www-data"
server.port                 = 80
#Server Tag ist der Name der angezeigt wird beim Abtasten des Servers (Nginx v.234)
server.tag                  = "Mein Server"


index-file.names            = ( "index.php", "index.html", "index.lighttpd.html" )
#Zugriff auf folgende Dateien untersagen
url.access-deny             = ( "~", ".inc" )
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )

compress.cache-dir          = "/var/cache/lighttpd/compress/"
compress.filetype           = ( "application/javascript", "text/css", "text/html", "text/plain" )

# default listening port for IPv6 falls back to the IPv4 port
include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port
include_shell "/usr/share/lighttpd/create-mime.assign.pl"
include_shell "/usr/share/lighttpd/include-conf-enabled.pl"

#Wir erlauben nur das die HTTP Requests Methoden GET & POST erlaubt sind

$HTTP["request-method"] !~ "^(GET|POST)" {
    url.access-deny = ("")
}

#Setzten der entsprechenden HTTP Headers, Achtung CSP anpassen

server.modules += ( "mod_setenv" )
$HTTP["scheme"] == "https" {
    setenv.add-response-header  = (
            "Content-Security-Policy"   => "default-src 'self'; script-src 'self'; object-src 'none'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self'; media-src 'self'; frame-src https://*.openstreetmap.org https://*.google.com; font-src https://fonts.googleapis.com; connect-src 'none'",
            "Strict-Transport-Security" => "max-age=15768000; includeSubDomains; preload",
            "X-Content-Type-Options" => "nosniff",
            "X-Frame-Options" => "DENY",
            "X-XSS-Protection" => "1; mode=block"
            )
}

#Umleiten von HTTP zu HTTPS

$HTTP["scheme"] == "http" {
    $HTTP["host"] =~ ".*" {
        url.redirect = (".*" => "https://%0$0")
    }
}

#Multi Webseiten Konfiguration

$HTTP["host"] =~ "(^|\.)example\.de$" {
    	server_name = "example.de"
        server.document-root = "/var/www/html/example.de" 
        server.errorlog = "/var/log/lighttpd/ex_de_error.log"	
}

$HTTP["host"] =~ "(^|\.)example\.com$" {
    	server_name = "example.com"
        server.document-root = "/var/www/html/example.com" 
        server.errorlog = "/var/log/lighttpd/ex_com_error.log"	
}

lighttpd SSL Konfiguration

Jetzt werden wir noch die SSL Konfiguration anpassen. Dazu bearbeiten wir die Datei /etc/lighttpd/conf-available/10-ssl.conf. Wir passen den Inhalt wir folgt an:

$SERVER["socket"] == ":443" {
    protocol     = "https://"
        ssl.engine   = "enable"
        ssl.disable-client-renegotiation = "enable"
        ssl.pemfile = "/etc/lighttpd/ssl/example.de.pem" 
        ssl.ca-file = "/etc/lighttpd/ssl/fullchain.pem"

        ssl.ec-curve              = "secp384r1"

        setenv.add-environment = (
                "HTTPS" => "on"
                )
        ssl.use-sslv2 = "disable"
        ssl.use-sslv3 = "disable"
        ssl.honor-cipher-order    = "enable"
        ssl.cipher-list           = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256"

        $HTTP["host"] =~ "(^|\.)example\.de$" {
            ssl.pemfile = "/etc/lighttpd/ssl/example.de.pem"
            ssl.ca-file = "/etc/lighttpd/ssl/fullchain.pem"
        }


    	$HTTP["host"] =~ "(^|\.)example\.com$" {
        	ssl.pemfile = "/etc/lighttpd/ssl/example.com.pem"
            ssl.ca-file = "/etc/lighttpd/ssl/fullchain.pem"
    	}
}

Dazu erstellen wir noch den folgenden Ordner

mkdir /etc/lighttpd/ssl/

Jetzt noch das SSL Modul aktivieren

lighttpd-enable-mod ssl
service lighttpd restart

Let's Encrypt

Bei lighttpd gibt es eine Besonderheit bei den Zertifikaten, so muss der Private Schlüssel und das Zertifikate in einer Datei sein und das CA immer als Referenz mit angebenen sein. Damit wir das nicht für jede Datei einzeln machen müssen, werden wird ein fertiges Script nehmen, was sich auch darum kümmert, die Zertifikate aktuell zu halten.

Dazu wechseln wir nach /opt. Dann klonen wir folgenden Repo:

git clone https://github.com/galeone/letsencrypt-lighttpd.git

Wechselt in den neuen Ordner letsencrypt-lighttpd. Als erstes bearbeiten wir die Datei letsencrypt-lighttpd.service und passen den ExecStart an nach /opt/letsencrypt-lighttpd/renew.sh.

ExecStart=/opt/letsencrypt-lighttpd/renew.sh

Dann kopieren die Service Dateien und starten den Dienst:

cp letsencrypt-lighttpd.* /etc/systemd/system/
systemctl enable letsencrypt-lighttpd.timer

Jetzt der "schwierige" Teil, wir passen noch renew.sh an:

#!/usr/bin/env bash 
set -eu

#Domain sudomain part (mail.example.de => mail)
domain_subdomains=( \
#domain     sub sub sub
"example.de w ww www" \
"example.com w ww www" \
)
email=mail@example.de
w_root=/var/www/html/ #Speicherort der Webseiten
user=root
group=root

# end configuration

if [ "$EUID" -ne 0 ]; then
    echo  "Please run as root"
    exit 1
fi

for domain_set_string in "${domain_subdomains[@]}"; do
    domain_set=(${domain_set_string// / })
    domain=${domain_set[0]}
    unset domain_set[0]

    all_subdomains="-d $domain"
    if [ ${#domain_set[@]} -gt 0 ]; then
        for sub_domain in "${domain_set[@]}"; do
            all_subdomains="$all_subdomains -d $sub_domain.$domain"
        done
    fi

    /usr/bin/certbot certonly --agree-tos --renew-by-default \
        --rsa-key-size 4096 --email $email --webroot -w $w_root$domain \
        $all_subdomains
    cat /etc/letsencrypt/live/$domain/privkey.pem \
        /etc/letsencrypt/live/$domain/cert.pem \
        > /etc/lighttpd/ssl/$domain.pem
    cp /etc/letsencrypt/live/$domain/fullchain.pem \
       /etc/lighttpd/ssl/
    chown -R $user:$group /etc/lighttpd/
	chmod 600 /etc/lighttpd/*.pem
done

Hinweis: Die Webseiten müssen im Ordner /var/www/html/ gespeichert werden, im Format der angegebenen Domain: /var/www/html/example.de

Jetzt starten wir die Dienste neu:

service php7.2-fpm restart
service lighttpd restart

Dann lassen wir uns noch die Zertifikate austellen

bash /opt/letsencrypt-lighttpd/renew.sh

Fazit

Der Lighttpd ist ein leistungsstarker Server, der wunderbar ein Ersatz für nginx und Apache sein kann.

6. Mai 2018

JSearchUtil ist ein Programm zum Suchen von Ordner in vorab definierten Pfaden. Es hat sich als äußerst effektiv erwiesen sobald ein Ordner in einem Verzeichnis mit sehr vielen anderen Ordnern und Verzeichnissen gesucht werden soll. In den meisten Betriebssystemen ist ein Suchfenster bereits vorgesehen, jedoch durchsuchen diese Funktionen häufig auch sämtliche Unterordner des Verzeichnisses. Das führt zu meist sehr langen Suchvorgängen. JSearchUtil sucht hingegenen nur auf Root-Verzeichnisebene, das heißt es wird vorab definiert in welchem Verzeichnissen gesucht werden soll. Im zweiten Schritt können diese Verzeichnisse nach einem Stichwort durchsucht werden. Die Ergebnisse werden gut sichtbar visualisiert und mittels Doppelklick kann das gewünschte Verzeichnis geöffnet werden. Die zur Suche genutzten Verzeichnisse werden automatisch im Hintergrund abgespeichert und sind beim nächsten Programmstart wieder verfügbar.

Screenshots:

Projektseite: klick

Download-Link: Klick

Github-Link: Klick

Angeregt durch Fryboyters Beitrag Alternative zu Isso habe ich mich auch mal wieder um meine Kommentarfunktion gekümmert. Commento ist leider noch nicht so weit, dass ich einen Umstieg von Isso erwägen würde, aber ich habe Isso immerhin auf den aktuellsten Entwicklungsstand gebracht. Es gibt zwar immer noch keine Benachrichtigungsfunktion aber immerhin kann man nun einen Feed zu den Artikelkommentaren abonnieren wenn man diese verfolgen möchte.

Ich habe Isso damals nach dieser Anleitung auf Uberspace 6 installiert und beschreibe wie man von dieser Basis auf den aktuellen Stand wechselt.

Zuerst installieren wir Isso und dessen Abhängigkeiten:

pip3.6 install flup werkzeug git+https://github.com/posativ/isso.git --user

Danach passen wir die Datei ~/fcgi-bin/isso folgendermaßen an (USER ist natürlich anzupassen):

#!/usr/bin/env python3.6

import os

from isso import make_app
from isso import config, dist

from flup.server.fcgi import WSGIServer

# load default configuration + user configuration
application = make_app(
    config.load(
        os.path.join(dist.location, dist.project_name, "defaults.ini"),
        "/home/USER/etc/isso/user.cfg"))

# start WSGI server
WSGIServer(application).run()

Anschließend müssen noch die aktuellen Javascript-Dateien in die Seite eingebaut werden. Ich habe dazu einfach das Repository geklont und den Ordner ./isso/js auf meine Seite hochgeladen und die Scripte folgendermaßen eingebunden:

<script src="/js/config.js"></script>
<script data-main="/js/embed" src="/js/components/requirejs/require.js"></script>
<script data-isso-vote="false" data-isso-lang="de" data-isso-feed="true" data-isso="/fcgi-bin/isso" src="/js/embed.js"></script>

Um die Beitragsfeeds zu aktivieren muss folgendes zur Konfiguration ~/etc/isso/user.cfg hinzugefügt werden:

[rss]
base = ../..
limit = 100

Ich habe base = ../.. gesetzt, da ich auf meiner Seite nur relative Links verwende, man kann natürlich auch einfach seine Domain eintragen.

Update 2018-05-07

Der Kommentarfeed wird jetzt auch im header der Blogeinträge verlinkt, auch wenn das leider kaum noch ein Browser prominent anzeigt1. 😔

Update 2018-05-07 #2

Mir ist gerade aufgefallen, dass die Links im Feed fehlerhaft sind. Ich weiß nicht, ob etwas mit meiner Anleitung nicht stimmt oder ob ich einen Fehler in dem Feature gefunden habe.

Update 2018-05-07 #3

Behoben. 😄 Es war ein kleiner Fehler in meiner config, den ich jetzt auch hier im Beitrag angepasst habe.

Update 2018-05-08

Ich habe eine Notiz bzgl. der Konfiguration base und einen Link zum Anzeigen von Feeds im Firefox hinzugefügt.

Linux ist bereits ein Nische aber verglichen mit FreeBSD fast schon Mainstream auf dem Desktop. Nichts desto weniger kann man auch FreeBSD in der aktuellen Inkarnation 11 auf dem Desktop installieren und produktiv nutzen. Die meisten Open Source Desktopumgebungen stehen für FreeBSD zur Verfügung. Seit vergangener Woche nun endlich auch Plasma 5.

Die Installation sollte natürlich - keine BSD-Erfahrugen vorausgesetzt - immer zum probieren in einer virtuellen Maschine, z. B. Virtualbox, erfolgen. Dazu lädt man sich am besten das Boot-Medium herunter, was dann alle benötigten Dateien aus dem Internet bezieht. Eine aktuelle ISO-Datei kann man auf der FreeBSD Homepage beziehen. Die Basisinstallation ist derart optionsarm, das hier keine weiteren Erläuterungen notwendig sind. Man kann im wesentlichen die Standardoptionen nehmen, wobei beim Umfang ports und lib32 nicht unbedingt notwendig sind. Zusätzlich legt man noch einen Benutzer an und wählt ein Root-Kennwort.

Plasma-Installation

Nach dem Neustart begrüßt einen die Konsole. Einen Desktop installiert FreeBSD nicht und überlässt dem Anwender hier somit die Wahl. Die folgende Anleitung installiert einen aktuellen Plasma 5 Desktop mit einem minimalen Anwendungsset.

Zuerst bringt man das neu installierte System auf einen aktuellen Stand mittels freebsd-update:

# freebsd-update fetch

# freebsd-update install

Anschließend installiert man pkg. Dieses stellt vereinfacht gesagt das Äquivalent zu APT oder Zypper dar.

# pkg

Plasma 5 ist noch relativ neu in den Quellen, weshalb man noch eine Änderung vornehmen muss. In der Konfigurationsdatei /etc/pkg/FreeBSD.conf ist folgende Zeile anzupassen:

url: “pkg+http://pkg.FreeBSD.org/${ABI}/quarterly”,

zu 

url: “pkg+http://pkg.FreeBSD.org/${ABI}/latest”,

Mittels folgenden Befehl anschließend die Paketquellen aktualisieren:

# pkg update

Anschließen installiert man zuerst X11. Von modernen "Spielereien" wie Wayland sollte man unter BSD erst einmal die Finger lassen.

# pkg install xorg xterm twm

Darauf aufbauen kann man nun den Plasma 5-Desktop, sowie SDDM für die Anmeldung installieren. Man kann auch das volle KDE-Paket kde5 installieren, aber dadurch bekommt man wirklich die komplette KDE-Suite auf das System. Ich persönliche empfehle immer eine Basisinstallation und dann ein hinzufügen benötigter Komponenten.

# pkg install plasma5-plasma-desktop sddm

Die nun installierten Pakete sind wirklich sehr minimal. Da ist außer dem puren Plasma-Desktop nichts enthalten. Für zusätzliche Basiskomponenten wie Dolphin oder den KDE-Terminal sollte zusätzlich folgendes Metapaket installiert werden:

# pkg install kde-baseapps

Anschließend sind noch einige Änderungen in den Konfigurationsdateien vorzunehmen. Hier ist FreeBSD immer noch sehr altmodisch und erinnert an das Arch Linux früherer Jahre.

In der Datei /etc/rc.conf sind folgende beiden Zeilen hinzuzufügen:

dbus_enable="YES"
sddm_enable="YES"

Sofern man beabsichtigt Kontact/Akonadi zu nutzen sind zudem folgende Änderungen in /etc/sysctl.conf nötig:

net.local.stream.recvspace=65536
net.local.stream.sendspace=65536

Sofern man Plasma in deutscher Sprache nutzen möchte ist noch eine Änderung in /etc/profile notwendig. Hier muss die folgende Zeile hinzugefügt werden:

LANG=de_DE; export LANG

SDDM erscheint nun standardmäßig mit dem wenig anumutigen Standarddesign und englischem Tastaturlayout. Insbesondere letzteres ist bei der Passworteingabe zu berücksichtigen. Nach der Anmeldung erscheint ein aufgeräumter Plasma-Desktiop.

Konfigurationshinweise

SDDM kann in der Datei /usr/local/etc/sddm.conf konfiguriert werden. Das grafische KCM-Modul ist zwar vorhanden, funktionierte im Test aber nicht zuverlässig.

 Viele weitere Optionen kann man dem Desktop HowTo.

Fazit

FreeBSD mit Plasma 5 funktioniert zufriedenstellend und lässt sich für in etwa die gleichen Aufgaben nutzen wie der Linux Desktop. Insbesondere bei Problemen und vielen Einstellungen muss man noch unter der Haube konfigurieren. So mancher Linux-Nutzer dürfte sich da in vergangene Zeiten zurück versetzt fühlen. Letztlich gibt es keinen zwingenden Grund für FreeBSD, weshalb Linux-Nutzern kein Wechsel angeraten werden kann. Wer aber mal einen Blick über den Tellerrand riskieren will, sollte es mal probieren. BSD ist schon lange nicht mehr unbenutzbar!


Bilder:

Einleitungs- und Beitragsbild von 3dman_eu via pixabay / Lizenz: CC0 Creative Commons

"

Ich habe mir jetzt doch Xubuntu 18.04 auf meinem Produktiv-Rechner installiert. Ich möchte wissen wie 18.04 läuft und wo es eventuell Probleme gibt.

Bionic Beaver
Xubuntu 18.04 Bionic Beaver

Hintergrund der Aktion ist, dass ich auf ubuntuusers.de am Wiki mitarbeiten möchte. Mir ist aufgefallen, dass viele Artikel seit mehreren Ubuntu-Versionen nicht mehr gepflegt werden.
Das Ubuntu Wiki ist auch immer eine Anlaufstelle für Anwender anderer Distributionen. Gerade deshalb finde ich es sehr wichtig, dass dieses Wiki aktuell gehalten wird. Ich denke wir erfahrenden Linux-User haben auch eine Verantwortung dafür, dass die Dokumentationen über GNU/Linux gepflegt werden. 🙂

5. Mai 2018

Am letzten Wochenende haben sich die Entwickler und Aktive rund um das linuxmuster.net Projekt zu einem Arbeitstreffen getroffen. Dort stellten sie unter anderem den aktuelle Stand zur neuen Version der Schulserverlösung vor. Die neue Version v7 wird ein großer Schritt um Vergleich zur aktuellen Version, da sich einige Dinge ändern werden. Darüber hatte ich bereits vor einigen Monaten gebloggt. Linuxmuster v7 soll bald als Alpha-Version verfügbar sein!

Releaseplan

Der Releaseplan sieht wie folgt aus, wobei der Grundsatz gilt: Es ist fertig, wenn es fertig ist!

  • Alpha Version → Mitte Mai 2018
  • Beta-Version → Juli 2018
  • Release von linuxmuster.net v7 → Dezember 2018

Es werden Tester gesucht, die bereit sind, die Alpha- und Beta-Versionen zu testen. Dazu kann man sich vorgefertigte Virtualbox-Images herunterladen. Eine Anleitung für die Ersteinrichtung und das Setup gibt es im Github-Repo des Projekts. Anleitung für die Ersteinrichtung

Die Protokolle der Arbeitstagungen werden i.d.R. im Vereinwiki des Projekts veröffentlicht.

Fazit

Persönlich freue ich mich sehr auf die neue Version von linuxmuster.net, denn die aktuelle Version funktioniert zwar gut und zuverlässig, doch technisch gesehen ist sie schon etwas in die Jahre gekommen (Samba3, Ubuntu 12.04). Auch der Wechsel zu einer neuen (besseren) Firewall finde ich gut, denn mit der neuen Version können wir unsere Firewall pfSense noch besser mit linuxmuster.net integrieren.

1 Kommentar

Der Beitrag Linuxmuster v7 bald als Alpha-Version verfügbar erschien zuerst auf .:zefanjas:..

4. Mai 2018

Ich habe hier vor einiger Zeit begonnen eine kleine Seite zu bauen, die es auch technisch weniger versierten einfacher machen soll in XMPP einzusteigen. Ziel war es JIDs in dieser Form an Kontakte zu geben und diese, falls sie XMPP noch nicht kennen, an die Hand zu nehmen und es jedem zu ermöglichen selbst einen Account zu erstellen, einen Client einzurichten und zu benutzen.

Leider hatte ich wenig Zeit das voranzutreiben und so ist die Seite leider noch in großen Teilen unvollständig und das Vorhandene teilweise vielleicht schon wieder veraltet.

Aus diesem Grund möchte ich den aktuellen Arbeitsstand heute mit diesem Blogpost bekannt machen und hoffe, dass der ein oder andere das Projekt sinnvoll findet und etwas dazu beitragen möchte.

Sollte die Seite einmal fertig werden könnte man auch über eine eigene Domain nachdenken. Die Seite wird mit Hugo generiert, liegt bei salsa.debian.org und ist CC BY-SA lizenziert, es kann also auch jeder einen Fork erstellen.

Die bisherigen Inhalte sollten auch ausreichend illustrieren wie die Seite einmal aufgebaut sein sollte:
Einfache Erklärungen, die für jeden verständlich sind, d.h. möglichst auf Fachbegriffe verzichten wo dies nicht unbedingt nötig ist und die Anleitungen sollten ausreichend mit Screenshots ausgestattet sein. Es sollte auch lieber eine Option gewählt und erläutert werden als neue User mit zu viel Wahlmöglichkeiten zu erschlagen, als konkretes Beispiel würde ich einen Client pro Betriebssystem erklären, statt erst den potentiellen XMPP-Nutzer mit den Vor- und Nachteilen bestimmter Anwendungen zu ermüden.

Natürlich kann man das alles noch unter Fortgeschrittene Themen unterbringen, aber die eigentliche Anleitung würde ich gerne so einfach wie möglich halten, damit sie leicht verständlich bleibt.

Update 2018-06-08

Das Repository ist von GitHub weggezogen.

Ich habe hier vor einiger Zeit begonnen eine kleine Seite zu bauen, die es auch technisch weniger versierten einfacher machen soll in XMPP einzusteigen. Ziel war es JIDs in dieser Form an Kontakte zu geben und diese, falls sie XMPP noch nicht kennen, an die Hand zu nehmen und es jedem zu ermöglichen selbst einen Account zu erstellen, einen Client einzurichten und zu benutzen.

Leider hatte ich wenig Zeit das voranzutreiben und so ist die Seite leider noch in großen Teilen unvollständig und das Vorhandene teilweise vielleicht schon wieder veraltet.

Aus diesem Grund möchte ich den aktuellen Arbeitsstand heute mit diesem Blogpost bekannt machen und hoffe, dass der ein oder andere das Projekt sinnvoll findet und etwas dazu beitragen möchte.

Sollte die Seite einmal fertig werden könnte man auch über eine eigene Domain nachdenken. Die Seite wird mit Hugo generiert, liegt bei salsa.debian.org und ist CC BY-SA lizenziert, es kann also auch jeder einen Fork erstellen.

Die bisherigen Inhalte sollten auch ausreichend illustrieren wie die Seite einmal aufgebaut sein sollte:
Einfache Erklärungen, die für jeden verständlich sind, d.h. möglichst auf Fachbegriffe verzichten wo dies nicht unbedingt nötig ist und die Anleitungen sollten ausreichend mit Screenshots ausgestattet sein. Es sollte auch lieber eine Option gewählt und erläutert werden als neue User mit zu viel Wahlmöglichkeiten zu erschlagen, als konkretes Beispiel würde ich einen Client pro Betriebssystem erklären, statt erst den potentiellen XMPP-Nutzer mit den Vor- und Nachteilen bestimmter Anwendungen zu ermüden.

Natürlich kann man das alles noch unter Fortgeschrittene Themen unterbringen, aber die eigentliche Anleitung würde ich gerne so einfach wie möglich halten, damit sie leicht verständlich bleibt.

Update 2018-06-08

Das Repository ist von GitHub weggezogen.

Da sich auf fryboyter.de einige menschliche Spambots herumtreiben ist Isso bei mir so eingestellt, dass ich für jeden neuen Kommentar eine E-Mail erhalte in dem dann ein Link zum Freischalten bzw. Löschen des Kommentars enthalten ist. Der Betreff dieser E-Mails war bei mir immer leer. Da ich die Kommentare aber problemlos moderieren konnte war mir das bisher egal. Naja eigentlich ist es mir immer noch egal.

Aufgrund des Commento-Artikels und des Kommentars von mdosch wegen der Datenübernahme von Isso habe ich mir eben einmal die Datenbankstruktur von Isso angesehen, weil ich morgen mal versuchen will ob ich es gebacken bekomme die Daten von Isso zu Commento zu portieren. In der Isso-Datenbank gibt es die Tabelle threads. In dieser ist die Spalte title vorhanden. Bei jedem Artikel den ich unter Bolt CMS erstellt habe und bei dem es Kommentare gibt ist hier die Spalte leer. Keine Ahnung wie Isso hier versucht den Titel des Artikels herauszufinden aber scheinbar klappt das bei mir nicht. Eventuell weil ich für die Titel den HTML-Tag H2 und nicht H1 nutze.

Auch wenn ich durch den fehlenden Betreff keine Nachteile habe, habe ich mich daran festgebissen. Die Lösung ist im Grunde aber in meinem Fall ganz einfach. Bisher wurde Isso wie folgt eingebunden:

<section>
    <h3>Kommentare</h3>
    <section id="isso-thread"</section>
</section>

In der Dokumentation von Isso findet man hier die Möglichkeit mit data-title=“” einen Titel vorzugeben. Das jedes mal manuell zu machen ist mir dann doch zu blöd. Twig sei Dank ist die Lösung aber trivial. Anstelle des Titels habe ich einfach {{ record.title }} eingetragen, so dass das ganze nun wie folgt aussieht.

<section>
   <h3>Kommentare</h3>
   <section id="isso-thread" data-title="{{ record.title }}"></section>
</section>

Damit wir nun die Spalte title befüllt und die E-Mails haben auch einen Betreff. Wenn nur alle Problem so leicht zu lösen wären. Vielleicht klappt der Import der Isso-Kommentare in Commento ja auch so einfach. Man darf ja noch träumen, oder?

3. Mai 2018

Humble Bundle bietet man aktuell einige Sachen zum Thema Python an. Da Python unter Linux ja dann doch ab und zu zum Einsatz kommt, habe ich gedacht ich weise einfach mal kurz darauf hin. Interessant ist hier für den einen oder anderen vielleicht auch der Gutschein über 50 US-Dollar bei DigitalOcean oder die Jahreslizenz von Gitkraken Pro.

Das ganze läuft noch 13 Tage und ein paar Stunden und ist unter https://www.humblebundle.com/software/python-dev-kit-bundle zu finden.

Containerisierung in der IT ist nicht mehr wegzudenken, viele sind mit Docker und Co schon einmal in Berührung gekommen.

Arbeit mit Docker bedeutet viel Konsolenarbeit. Ein docker ps da oder ein docker save dort. Um diese Arbeit zu vereinfachen wurde Portainer entwickelt.

Portainer – Open Source Container Dashboard

Das Open Source Tool erlaubt einen Überblick und eine Bearbeitung der vorhandenen Docker Container, ist unter Linux leicht zu installieren (natürlich als Docker Container) und benötigt anders als Rancher nicht zwingend ein signiertes TLS Zertifikat.

Auch das Erstellen von neuen Containern oder eine Beschränkung auf bestimmte Nutzergruppen ist über die Oberfläche einfach zu realisieren.

Über jeden Container lassen sich ausführliche Informationen wie Logs, Pfade oder Laufzeit auslesen. Selbst eine Konsole lässt sich über die Verwaltung starten.

portainer

Eine eigene Installation ist schnell erstellt.

Zunächst kann das Docker Dashboard einfach ohne TLS gestartet werden.

docker volume create portainer_data

docker run -d -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer

Der Aufrug erfolgt dann über den Browser und http://local-IP:9000

Für einen dauerhaften Betrieb würde sich ein persistenter Ordner, sowie ein Autostart anbieten. Sollte SELinux im Einsatz sein, muss zusätzlich mit „privileged“ gearbeitet werden.

docker run -d --privileged -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v /path/on/host/data:/data portainer/portainer

In den Standardeinstellungen speichert Portainer seine Daten unter /data.

Auch ein individueller Remote Host ist möglich

docker run -d -p 9000:9000 portainer/portainer -H tcp://<REMOTE_HOST>:<REMOTE_PORT>

Portainer-Remote

Portainer mit TLS zu verwenden benötigt weitere Befehle.

docker run -d -p 9000:9000 -v /path/to/certs:/certs portainer/portainer -H tcp://<DOCKER_HOST>:<DOCKER_PORT> --tlsverify --tlscacert /certs/myCa.pem --tlscert /certs/myCert.pem --tlskey /certs/myKey.pem

Eine ausführliche Portainer Dokumentation bietet noch mehr Möglichkeiten zur Konfiguration an

 

Fazit

Für eine einfache und praktische Verwaltung von Docker Containern ist Portainer wirklich gut zu gebrauchen. Es bietet genügend Funktionen an, um sich einen Überblick zu verschaffen.

Portainer erlaubt dank einer integrierten Nutzerverwaltung und der Möglichkeit Container auszublenden auch eine Verwendung im professionelleren Umfeld. Neben der Einbindung eines eigenen Logos werden sogar Windows Container unterstützt.

Probiert es mal aus, eine vorhandene Docker Umgebung kann damit gut ergänzt werden.

Download Portainer

 

Die größte Überraschung bei Fedora 28 besteht darin, dass die Distribution erstmals seit Jahren pünktlich ausgeliefert wurde. Aber auch sonst gibt es einige interessante Details, z.B. die vereinfachte Installation (Fedora Workstation) oder Pakete in unterschiedlichen Versionen (Fedora Server).

Installation

Der Installationsprozess (getestet für die Gnome-Desktop-Variante vom Live-Abbild, Download hier) wurde in zwei Punkten vereinfacht: es gibt keine Option zur Aktivierung des Netzwerks mehr (es ist automatisch aktiv), und auch das Einrichten eines Benutzer-Acoounts entfällt. (Darum kümmert sich der Willkommens-Assistent von Gnome beim ersten Login.)

Der Hauptdialog des Installationsprogramms wurde vereinfacht.
Der Benutzer-Account wird beim ersten Start eingerichtet.

Bemerkenswert ist auch, dass root wie unter Ubuntu kein Passwort mehr erhält. Ein direkter root-Login ist somit unmöglich — ein Sicherheitsgewinn. Der unter Gnome eingerichtete erste Benutzer hat sudo-Rechte. (Die Neuerungen bei der Benutzerverwaltung gelten nur für die Desktop-Version, nicht für Fedora Server, wo es weiterhin einen aktiven root-Nutzer gibt.)

Wie in den vergangenen Fedora-Versionen ist Wayland das Default-Grafiksystem. Xorg steht als Alternative weiter zur Verfügung, allerdings merkwürdigerweise nicht beim ersten Login.

Neuerungen

Das Gnome-Programm Software fragt beim Start, ob Paketquellen von Drittanbietern eingerichtet werden sollen. Auch wenn Sie dieser Anfrage zustimmen, werden die Quellen nicht gleich aktiviert. Das müssen Sie im Panel-Menüeintrag Softwarequellen selbst erledigen. Vorgesehen sind Paketquellen für die Pyhton-IDE PyCharm, für Google Chrome sowie natürlich RPM Fusion.

Auch die Aktivierung externer Paketquellen hat sich vereinfacht.

Die Fedora-Entwickler betonen in den Release Notes, dass Fedora auf Notebooks nun spürbar längere Laufzeiten erzielen sollte, weil diverse Energiesparmaßnahmen nun standardmäßig aktiv sind. Ich habe diese Funktionen allerdings nicht getestet und kann nicht sagen, wie stark sie sich auswirken und ob es zu negativen Nebenwirkungen kommt. Vermutlich hängt dies stark vom jeweiligen Notebook-Modell ab.

Ebenfalls vor allem bei modernen Notebooks interessant ist die stark verbesserte Thunderbolt-Unterstützung, die ich aber mangels geeigneter Hardware ebenfalls nicht getestet habe. Hintergrundinformationen können Sie hier nachlesen.

Praktisch für alle, die Fedora in VirtualBox ausführen möchten: Die bisher erforderliche Installation der Gast-Treiber entfällt. Diese sind nun standardmäßig installiert, einige Funktionen sind mittlerweile ja auch direkt in den Kernel integriert (Kurzbericht auf phoronix).

Versionsnummern

Basis            Desktop             Programmierung   Server
--------------   ------------------  --------------   --------------
Kernel    4.16   Gnome        3.28   bash       4.4   Apache     2.4
glibc     2.27   Firefox        59   gcc        8.0   CUPS       2.2
X-Server  1.19   Gimp          2.8   Java        10   MariaDB   10.2
Wayland   1.14   LibreOffice   6.0   PHP        7.2   OpenSSH    7.7
Mesa        18   Thunderbird    52   Python     3.6   qemu/KVM  2.11
Systemd    238                                        Postfix    3.2
NetworkMan 1.10                                       Samba      4.8
GRUB       2.02 

Flatpak ist installiert und vorkonfiguriert; anders als Ubuntu verzichtet Fedora aber darauf, standardmäßig irgendwelche Flatpak-Pakete zu installieren.

Fedora Server

Mit einem Wartungszeitraum von gut einem Jahr ist Fedora Server für den Praxiseinsatz weitestgehend ungeeignet. Es erfüllt vielmehr seine Aufgabe als Testvehikel für die jeweils nächste RHEL-Version. Im Vergleich zu Ubuntu Server fällt auf, dass das Installations-Image mit 2,7 GByte riesig ist. (Ubuntu Server begnügt sich mit 800 MByte.) Der tatsächliche Platzbedarf auf der Festplatte bei Beibehaltung der Default-Optionen für die Paketauswahl (d.h. kein Desktop, keine zusätzlichen Server-Dienste) ist dann aber auch bei Fedora mit ca. 1,4 GByte bescheiden.

In der Fedora-Server-Edition ist das neue Modularity-Konzept realisiert. Es sieht parallele Paketquellen für unterschiedliche Software-Versionen vor und erlaubt es, Pakete je nach Bedarf in einer bestimmten Version zu installieren — z.B. nodejs 8 (per Default in Fedora 28) oder nodejs 6 aus der Paketquelle fedora-modular oder nodejs 10 aus der Paketquelle updates-testing-modular. Parallelinstallationen unterschiedlicher Versionen sind allerdings nicht vorgesehen.

Hinter den Kulissen definieren einige Dateien /etc/yum.repos.d/fedora*modular.repo die neuen Modularity-Paketquellen. Wenn Sie Modularity in der Fedora-Desktop-Version ausprobieren möchten, installieren Sie einfach das Paket fedora-repos-modular.

cd /etc/yum.repos.d/

ls fedora*modular.repo
  fedora-modular.repo  
  fedora-updates-modular.repo  
  fedora-updates-testing-modular.repo

cat /etc/yum.repos.d/fedora-modular.repo
  [fedora-modular]
  name=Fedora Modular $releasever - $basearch
  failovermethod=priority
  #baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Modular/$basearch/os/
  metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-$releasever&arch=$basearch
  enabled=1
  ...

Das dnf-Kommando wurde um das Subkommando module erweitert. Mit dnf module install paket:version bzw. in der Kurzschreibweise dnf install @paket:version kann ein Paket in einer bestimmten Version installiert werden. dnf module list --all paket listet alle zur Auswahl stehenden Versionen eines Pakets auf. Weitere Details zu dnf module ... gibt man dnf. Im Internet habe ich allerdings noch keine aktuelle man-Seite des erweiterten dnf-Kommandos gefunden.

dnf module list --all nodejs
  Fedora Modular 28 - x86_64
  Name      Stream      Version            Profiles                            
  nodejs    6           20180308155546     default, development, ...           
  nodejs    8           20180308143646     default, development, ...           
  nodejs    9           20180308142225     default, development, ...           

  Fedora Modular 28 - x86_64 - Test Updates
  Name      Stream      Version            Profiles                            
  nodejs    10          20180501175322     default, development, ...           
  nodejs    8           20180328183715     default, development, ...           
  nodejs    9           20180405175619     default, development, ...           

dnf install nodejs
  ===============================================================================
   Paket                   Arch          Version             Paketquelle   Größe
  ===============================================================================
  Installieren:
   nodejs                  x86_64        1:8.11.0-1.fc28     fedora        5.5 M
  ...

dnf install @nodejs:10
  ==========================================================================================
   Paket   Arch    Version                                   Paketquelle              Größe
  ==========================================================================================
  Installing module packages:
   nodejs  x86_64  1:10.0.0-1.module_1716+9b6ad2c1           updates-testing-modular  7.7 M
  ...


dnf install @nodejs:6
  ================================================================================
   Paket            Arch   Version                           Paketquelle    Größe
  ================================================================================
  Installing module packages:
   nodejs           x86_64 1:6.13.1-1.module_1575+55808bea   fedora-modular 4.9 M
  ...

Aktuell ist das Modularity-Konzept stark eingeschränkt realisiert. Es gibt nur wenige Pakete, die tatsächlich in unterschiedlichen Versionen zur Auswahl stehen. (Werfen Sie z.B. einen Blick ein die fedora-modular-Paketquelle, hier auf dem Mirror der Uni Frankfurt. Neben dem bereits erwähnten nodejs-Paketen finden Sie dort nur npm und einige Python-Module.)

Quellen

2. Mai 2018

Im Herbst 2016 hatte Mozilla das Projekt Mortar angekündigt. In dessen Rahmen hatte Mozilla damit experimentiert, den von Google entwickelten PDF-Betrachter PDFium in Firefox zu integrieren sowie das in Chrome genutzte Pepper-Plugin des Adobe Flash Players in Firefox zu verwenden anstelle des bisherigen NPAPI-Plugins. Das Projekt wurde nun offiziell gestoppt.

Mozilla hatte im Oktober 2016 das Projekt Mortar angekündigt. Ziel dieser Initiative war es, den Fokus noch stärker als bisher darauf zu legen, das Web weiterzuentwickeln und die Komplexität sowie den Wartungsaufwand von Firefox zu reduzieren. Konkret sollte dabei die Zeit reduziert werden, die Mozilla in Technologien investieren muss, welche für einen Browser zwingend erforderlich sind, damit das Web vollständig genutzt werden kann, aber kein elementarer Bestandteil der eigentlichen Web-Plattform sind.

Speziell hatte sich Mozilla dabei mit zwei Thematiken befasst: Mozilla selbst entwickelter PDF-Betrachter pdf.js sollte durch PDFium von Google ersetzt werden und der Adobe Flash Player sollte über eine Untermenge von Googles Pepper-API bereitgestellt werden anstelle der bisherigen NPAPI-Schnittstelle.

Nachdem das Projekt vor einigen Monaten bereits depriorisiert worden ist, folgte nun das offizielle Aus. Mozilla ist zu dem Entschluss gekommen, dass die Implementierung und Wartung von PDFium und der Pepper-API den Aufwand nicht ausreichend rechtfertigt.

Was Pepper-Flash betrifft, kommt mit Sicherheit auch dazu, dass seit vergangenem Jahr bekannt ist, dass die Unterstützung für den Adobe Flash Player Anfang 2020 komplett eingestellt werden wird.

Der Beitrag Mortar gestoppt: Kein PDFium und Pepper-Flash für Firefox erschien zuerst auf soeren-hentzschel.at.

Gimp ist der erste Prüfstein für die neuen Paketverwaltungssysteme Snap und Flatpak. Der Versuch, Gimp unter Ubuntu 18.04 zu installieren, verläuft aber holprig.

Gimp 2.10

Aktualisiert am 9.5.2018 und am 15.5.2018.

Snap: Es ist fast soweit …

snapcraft.io bietet Gimp aktuell in allen Channeln (stable, candidate, beta und edge) nur in der Version 2.8 an. Enttäuschend.

Update 9.5.2018: Gimp 2.10 ist jetzt snapcraft.io erhältlich. Platzbedarf 210 MByte, also mehr als das PPA-Paket (siehe unten), aber immerhin deutlich weniger als im Flatpak-Format, wo zusätzlich das Gnome-Plattform-Paket installiert werden muss.

Das Snap-Paket hat allerdings ein großes Problem: Gimp zeigt nur englische Menüs an. Die Lokalisierung funktioniert nicht. Das Problem ist bekannt, es ist auf GitHub diesbezüglich aber seit Sept. 2017 keine Aktivität zu erkennen.

Update 15.5.2018: Gimp 2.10 steht jetzt als Release Candidate mit korrekter Lokalisierung zur Verfügung (Installation mit sudo snap install --candidate gimp).

Interessant ist hingegen, dass in Ubuntu-Software eingestellt werden kann, aus welchen Verzeichnissen Gimp Bilder laden und bearbeiten darf.

Berechtigungen für das Gimp-Snap-Paket in »Ubuntu-Software« einstellen

Flatpak: Ja, aber …

Deutlich besser sieht die Lage auf flathub aus. Dort steht Gimp in der aktuellen Version 2.10 zur Verfügung.

Flatpak kann für Ubuntu-Software unkompliziert als Paketquelle eingerichtet werden:

sudo apt install flatpak gnome-software-plugin-flatpak

sudo flatpak remote-add --if-not-exists flathub \
        https://flathub.org/repo/flathub.flatpakrepo

Dennoch scheitert der Versuch, Gimp nun in Ubuntu-Software zu installieren. Dort ist Gimp ganz einfach nicht zu finden. Ubuntu-Software zeigt das Snap-Paket von Gimp (2.8) und das Debian-Paket von Gimp (auch 2.8), aber nicht das Flatpak-Paket.

Immerhin gelingt die Installation problemlos in einem Terminal:

sudo flatpak install flathub org.gimp.GIMP

Dabei wird nicht nur Gimp an sich installiert, sondern auch die Laufzeitumgebung org.gnome.Platform/x86_64/3.28. Gesamtplatzbedarf laut flatpak list -d: fast 1 GByte:

flatpak list -d
  Ref                             Origin  Active commit Latest commit Installed size Options       
  org.gimp.GIMP/x86_64/stable     flathub db163ad29c6c  -             160,1 MB       system,current
  org.gnome.Platform/x86_64/3.28  flathub f78d82e0dbe1  -             787,6 MB       system,runtime

PPA: noch immer am einfachsten

Es gibt Gimp auch in einem Private Package Archive (PPA). Allen neuen Paketformaten zum Trotz ist das der einfachste und platzsparendste Weg, um Gimp zu installieren. OMG Ubuntu empfiehlt, Gimp 2.8 zu deinstallieren, bevor das PPA eingerichtet wird (apt remove gimp*).

sudo apt remove gimp*
sudo add-apt-repository ppa:otto-kesselgulasch/gimp
sudo apt update
sudo apt install gimp

Die folgenden zusätzlichen Pakete werden installiert:
  gimp-data libamd2 libbabl-0.1-0 libcamd2 libccolamd2 libcholmod3 libgegl-0.3-0 libgegl-0.4-0 libgfortran4 libgimp2.0 libjavascriptcoregtk-1.0-0 liblapack3 libmetis5
  libmng2 libmypaint libumfpack5 libwebkitgtk-1.0-0 mypaint-brushes
Vorgeschlagene Pakete:
  gimp-help-en | gimp-help gimp-data-extras
Die folgenden NEUEN Pakete werden installiert:
  gimp gimp-data libamd2 libbabl-0.1-0 libcamd2 libccolamd2 libcholmod3 libgegl-0.3-0 libgegl-0.4-0 libgfortran4 libgimp2.0 libjavascriptcoregtk-1.0-0 liblapack3 libmetis5
  libmng2 libmypaint libumfpack5 libwebkitgtk-1.0-0 mypaint-brushes
0 aktualisiert, 19 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 35,5 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 161 MB Plattenplatz zusätzlich benutzt.
...

Infos über Gimp 2.10

Gimp 2.10 ist die erste neue Gimp-Version nach 2.8, das vor sechs Jahren (!) veröffentlicht wurde. Gimp 2.10 wurde umfassend erweitert und in seiner Struktur erneuert. Informationen über neue Funktionen können Sie z.B. hier nachlesen:

Als ich von Wordpress auf Bolt CMS umgestiegen bin, hatte ich mich für das Kommentarsystem Isso entschieden, da Bolt CMS solch eine Funktion nicht bietet. Gerade überlege ich mir aber, ob ich bei Isso bleibe.

Der Grund hierfür ist nicht, dass Isso Probleme im laufenden Betrieb macht. Der Grund ist auch nicht, dass Isso mit Python realisiert wird. Der Grund ist der, dass einfach keine neue offizielle Version veröffentlicht wird obwohl sich zwischenzeitlich einiges bei Isso getan hat. Wie zum Beispiel die RSS-Funktion die ich für verdammt nützlich ansehe, da man bei neuen Kommentaren ja nicht per E-Mail benachrichtigt wird. Somit nutze ich derzeit die letzte offizielle Version vom September 2016.

Aber welche Alternative kommt in Frage? Da ich die Kommentare nicht in die Hände Dritter geben will, kommen Lösungen wie Disqus definitiv nicht in Frage. Viele Alternativen zum selber hosten wie Hashover kommen ebenfalls nicht in Frage, da die Entwicklung entweder eingestellt wurde bzw. sehr langsam voranschreitet.

Am vielversprechensten finde ich derzeit Commento. Das Projekt ist zwar noch ziemlich am Anfang, wird aber bereits von von Mozilla und DigitalOcean gesponsort und die letzte offizielle Version (0.3.1) ist erst knapp einen Monat alt. Allerdings fehlt derzeit noch die Möglichkeit die Kommentare zu moderieren. Daher bin ich aktuell noch etwas unsicher ob ich derzeit wechseln soll oder nicht. Zumal sich auf fryboyter.de auch der eine oder andere menschliche Spambot herumtreibt. Da Isso, wie schon gesagt derzeit keine technischen Probleme bereitet, werde ich Commento einfach mal ein paar Wochen / Monate beobachten. Mal schauen wie sich das Projekt entwickelt.

1. Mai 2018

Vor gut einem Monat hat Google angekündigt, seinen hauseigenen URL-Shortener goo.gl einzustellen. Schade, denn ich habe den Dienst sehr gerne genutzt, um z.B. Artikel auf Twitter zu verteilen. URL-Shortener ermöglichen es, aus einer langen URL eine kurze zu erstellen, welche dann auf die ursprüngliche weiterleitet.

Darin steckt auch einer der Gründe und vormals Notwendigkeiten solcher Dienste, denn bevor Twitter eigene Maßnahmen zur Verbesserung von Links in Tweets ergriff (z.B. Einführung von t.co), waren die Services der einzige Weg, um halbwegs einen Link in den 140 Zeichen unterzubringen. Es wurde dafür in Kauf genommen, dass die entstandenen URLs alles andere als lesbar waren – sie sollten einfach nur funktionieren. 26 Groß- und Kleinbuchstaben und die zehn Ziffern bilden schon bei einer Zeichenlänge von konstant 5 Zeichen über 900 Millionen Möglichkeiten. ((26 + 26 + 10)5) Bitly ging als einer der bekanntesten Dienste hervor.

Auch nach der Anpassung seitens Twitter blieben die URLs trotz einiger Sicherheitsbedenken, denn man weiß auf den ersten Blick nicht, wohin man geleitet wird, weiter beliebt. Unternehmen wie Google nutzen für Firmeninhalte eigene URL-Shortener (z.B. g.co), um kürzere URLs zu erstellen – mit dem Unterschied, dass diese URLs klanghaft (Stichwort Vanity URLs) sind, man sich diese auch merken kann. So führt g.co/recover zum Wiederherstellungsprozess eines Google-Kontos.

Vorteil einer solchen Variante ist es, dass kürzere und merkfähigere URLs erstellt werden können, ohne die URL-Struktur einer Seite in ihrer Beständigkeit einzuschränken, denn Cool URIs don’t change. (zumindest die Canonical-URLs)

Warum also nicht einen Linkshortener auch auf der eigenen Seite einsetzen? Ziel sollte es sein, die Funktionalität für die eigenen Seite bereitzustellen und auch die komplette Kontrolle über den Shortener-Service zu behalten.

Und es gab für mein Einsatzszenario noch eine Besonderheit: das zugrunde liegende System bzw. Script sollte so klein und einfach wie möglich sein. One file. KISS eben. Deswegen fiel leider Yourls raus, weil es aus meiner Sicht für diesen Zweck etwas zu anspruchsvoll ist. Wer eine leistungsfähigere Lösung braucht, ist mit Yourls gut bedient, ich will aber z.B. nur v-gar.de/-mysql-1698 zu meinem MySQL-Artikel weiterleiten.

So entstand Atajlio. Die Installation ist denkbar einfach: index.php herunterladen, u.U. umbenennen, auf den Webspace packen, sicherstellen, dass PHP sowie der PHP PDO-SQLite-Support laufen (ist i.d.R. der Fall) und das Script in dem Verzeichnis schreiben kann und die File über den Webserver aufrufen. Nach erfolgreicher Initialisierung (d.h. ./atajlio.db wird angelegt, Pfad lässt sich aber vorher umkonfigurieren) wird eine Admin-URL einmalig angezeigt. Diese merken bzw. sichern, sie ist der Zugang für die Verwaltungskonsole. Jetzt ein URL-Rewriting konfigurieren und z.B.
example.com/-XXX auf example.com/atajlio/?l=XXX mappen.

Abschließend example.com/-adminurl entsprechend aufrufen, UNBEDINGT den Zugriff auf die DB-File (in .htaccess bzw. Webserver-Configfile) sperren – fertig.

Der Source Code liegt bei GitHub und steht unter der MIT-Lizenz.

Das Projekt soll weiterentwickelt sowie dokumentiert werden und ich überlege momentan, doch noch einige Einstellungsmöglichkeiten für z.B. MySQL einzubauen, bin aber mit dem aktuellen Ergebnis in der Funktionsweise schon ganz zufrieden.

Selbstverständlich freue ich mich über jedes Feedback!