ubuntuusers.de

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.

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:

• SSL Labs
• High-Tech Bridge
• Obervatory by Mozilla

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.

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.

Seit kurzem läuft auf meinem Server ein XMPP (Jabber) Server auf dem sich jeder registrieren kann.

Die wichtigsten Daten im Überlick:

Domain: malte-kiefer.de

XEP’s: 0368, 0163, 0191, 0198, 0237, 0280, 0352, 0363, 0313, 0357, 0384, 0368

HTTP-BIND: https://malte-kiefer.de/http-bind

Checks

• CryptCheck
• IM Observatory

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:

• SSL Labs
• High-Tech Bridge
• Obervatory by Mozilla

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.

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 anzeigt¹. 😔

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.

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.

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

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?

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.

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

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

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.

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

• Download
• Release Notes
• Change Set
• Common Bugs
• Bericht über Third-party Repositories im Fedora Magazine
• Details zu den Notebook-Energiesparmaßnahmen
• Thunderbolt Enablement
• Fedora Modularity
• Fedora Modularity (Vorschau im communityblog.fedoraproject.org)

• Test von heise.de
• Test von derstandard.at
• Test von golem.de
• Fedora auf distrowatch.com
• Test von pro-linux.de

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.

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.

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:

• https://www.gimp.org/release-notes/gimp-2.10.html
• https://www.gimp.org/news/2018/04/27/gimp-2-10-0-released
• https://www.heise.de/newsticker/meldung/Gimp-2-10-und-das-alte-Versprechen-der-neuen-Engine-4028769.html
• https://www.tutonaut.de/gimp-2-10-neue-features-im-bild-plus-beta-tools-freischalten/

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.

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)⁵) 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!

Mit der bevorstehenden Veröffentlichung von Mozilla Thunderbird 60 bekommt der freie E-Mail-Client nicht nur neue Funktionen und optisch einen überarbeiteten Anstrich, ähnlich wie bei Firefox mit Version 57 wird auch das Logo von Thunderbird erneuert. Dieser Artikel enthüllt, wie das neue Logo aussehen soll.

Mit Firefox 57 hat Mozilla seinen Browser grundlegend verbessert. Die Änderungen waren so groß, dass es Mozilla für den idealen Zeitpunkt hielt, auch das Firefox-Logo zu modernisieren. Nun steht die Veröffentlichung von Thunderbird 60 kurz bevor, dem ersten großen Update seit Thunderbird 52 vor einem Jahr.

Neben dem neuen Firefox-Logo sieht das bisherige Thunderbird-Logo nicht mehr ganz auf der Höhe der Zeit aus. Um das zu ändern, hat die Thunderbird-Community in Anlehnung an das neue Firefox-Logo das Logo von Thunderbird überarbeitet. Das Thunderbird-Konsul hat dem neuen Logo gestern zugestimmt, jetzt muss es nur noch von der Mozilla Foundation freigegeben werden.

Der Beitrag Das ist das neue Thunderbird-Logo erschien zuerst auf soeren-hentzschel.at.

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!

Wählt man bei Online-Händlern die Zahlungsweise Kreditkartenzahlung aus, wird man heute in den meisten Fällen mit dem Verfahren 3-D Secure [1] konfrontiert. Je nachdem welche Kreditkarte man verwendet, heißt das Verfahren Verified by Visa oder bei einer Mastercard SecureCode.

Durch das Verfahren sollen Zahlungsausfälle durch Kreditkartenmissbrauch reduziert werden. Teilnehmenden Online-Händlern wird zudem der Zahlungseingang garantiert, wenn sie 3-D Secure einsetzen.

Doch welche Vorteile bietet dieses Verfahren für den Kunden? Auf den ersten Blick gar keine. Statt eines Passwortes muss der Kunde sich nun eine PIN für die Banking-App bzw. für sein mobiles Endgerät merken.

Im Wikipedia-Artikel zu 3-D Secure [1] wird zudem ausgeführt:

Auch im Jahr 2018 gibt es jedoch noch Konstellationen, in denen die Haftungsfrage eindeutig zu Lasten des Kunden ausfällt und die Registrierung zu 3-D Secure ein im Vergleich zu anderen Zahlungswegen für den Kunden außergewöhnlich riskantes Verfahren sein kann, wie folgender Fall verdeutlicht: Die DKB hat vom statischen Sicherheitscode auf einen dynamischen Code per App oder mTAN umgestellt. In ihren Sonderbedingungen für 3-D Secure legt die DKB aktuell einen Haftungsausschluss für den Fall fest, „dass das mobile Endgerät verloren, gestohlen oder weitergegeben wird und dadurch Dritte ggf. Zugriff auf SMS erhalten und diese unberechtigt nutzen können“. Bei einem möglichen gleichzeitigen Verlust von Kreditkarte und Mobilfunkgerät kann ein Finder also beliebige Zahlungen zu Lasten des Besitzers auslösen und verifizieren, vorausgesetzt er bekommt Zugang zum Mobilgerät (etwa durch eine einfache Tastensperre). Für diese missbräuchlichen Zahlungen haftet der Kunde vollständig bis zur Sperrung der Karte, bei einer Zahlung ohne 3-D Secure haftet er dagegen nur bis maximal 50 €. Bei Verlust stellen weder die auf der Karte aufgedruckten Daten, noch das 3-D-Secure-Verfahren eine Hürde für den einfachen Missbrauch dar, sondern lediglich die PIN oder vergleichbare Sicherungsmechanismen des Mobilgeräts. Das Risiko für den Kunden ist in dieser Konstellation höher, als ohne Registrierung zum 3-D-Secure-Verfahren, unabhängig davon, ob der Kunde 3-D Secure überhaupt benutzt.

Diese Aussage ließ mich zunächst zweifeln, ob ich mich überhaupt noch zum dynamischen 3-D Secure Verfahren anmelden sollte. Ich beschloss daher, die Sonderbedingungen für das 3D Secure Verfahren bei Internet-Zahlungen mit der DKB-Kreditkarte [2] genau zu lesen und im Zweifel bei meiner Bank nachzufragen, wie es sich mit der Haftung verhält.

Aus den Sonderbedingungen für das 3D Secure Verfahren bei Internet-Zahlungen mit der DKB-Kreditkarte

Im Folgenden zitiere ich aus den oben genannten Sonderbedingungen [2] und liste die Fragen auf, welche durch die genannten Punkte aufgeworfen wurden.

Sorgfaltspflichten des Karteninhabers

Hier Punkt 1:

1) Der Karteninhaber
a) hat das Risiko eines unberechtigten Zugriffs auf sein mobiles Endgerät u. a. durch geeignete Schutzmaßnahmen zu minimieren (z.B. PIN auf mobiles Endgerät).
b) hat das Betriebssystem des von ihm verwendeten Endgerätes auf dem neuesten Stand zu halten.
c) hat die App nur aus offiziellen App-Stores (iTunes, Google Playstore, Windows Store) herunterzuladen und dafür vorgesehene Updates regelmäßig durchzuführen.

Während Punkt a) noch einleuchtet, wirft Punkt b) bereits erste Fragen auf. Was mache ich, wenn mein Endgerät schon älter ist und der Hersteller keine Updates mehr für das Betriebssystem veröffentlicht? Was ist, wenn ich mir im Handel ein neues Android-Gerät kaufe, welches mit einer älteren Android-Version ausgeliefert wird und vom Hersteller ebenfalls keine Updates mehr für das Betriebssystem erhält? Darf ich in oben genannten Fällen überhaupt noch am 3-D Secure Verfahren teilnehmen? Oder darf die DKB in diesen Fällen bereits die Haftung im Missbrauchsfall ablehnen?

Zu Punkt 3:

Die DKB AG haftet nicht für den Fall, dass das mobile Endgerät verloren, gestohlen oder weitergegeben wird und dadurch Dritte ggf. Zugriff auf SMS erhalten und diese unberechtigt nutzen können.

Dies ist der Punkt, welcher bereits im Wikipedia-Artikel [1] kritisiert wurde. Hier stellt sich die Frage, ob ich mich mit einer Teilnahme an 3-D Secure nicht schlechter stelle.

Verantwortlichkeit und Haftung

Punkt 7 der Sonderbedingungen [2] widmet sich dann konkret der Haftung:

[…] Die DKB AG übernimmt außerdem keine Haftung bei Manipulation des mobilen Endgeräts (z.B. Jailbreaking, Rooting).

Bedeutet dies, dass Nutzer freier bzw. alternativer Betriebssysteme das Verfahren nicht nutzen können? Schließlich sind Jailbreaks und Rooting oftmals Voraussetzung, um ein Custom-ROM auf ein Endgerät aufspielen zu können.

Mit obigen Fragen habe ich mich per E-Mail an die DKB gewendet und um schriftliche Antwort gebeten.

Die Antwort der DKB

Eine Antwort ließ nicht lange auf sich warten. Man bat darum, die Sache zunächst am Telefon zu erörtern. Auf Wunsch bestätigte man mir die wesentlichen Inhalte dann auch schriftlich.

Nach Aussage eines Mitarbeiters aus der Technik wurde die DKB Secure App so entworfen, dass sie den Patchlevel des mobilen Betriebssystems prüfen und erkennen kann, ob das Gerät gerootet bzw. gejailbreakt wurde. Ist letzteres der Fall oder ist der Patchlevel des Endgerätes zu alt, verweigert die App den Start.

Mir wurde bestätigt, dass dies im Umkehrschluss bedeutet, dass wenn die App startet, die Sorgfaltspflicht aus Punkt 1.b) als erfüllt angesehen werden kann.

Die schlechte Nachricht für die Freunde freier Betriebssysteme ist, dass die DKB jegliche Haftung ablehnt, wenn die App nicht aus den offiziellen App Stores bezogen wurde und/oder unter einem Custom-ROM betrieben wird. Der Haftungsausschluss gilt in diesem Fall übrigens auch, wenn man statt der App das mTAN-Verfahren via SMS nutzen möchte.

Steht noch die Antwort zu Punkt 3 aus. Hierzu teilte mir eine Mitarbeiterin aus der Fachabteilung Privatkundenservice mit, dass die Haftung bei Diebstahl des mobilen Endgeräts nur dann ausgeschlossen ist, wenn der Kunde grob fahrlässig gehandelt hat. Unter grobe Fahrlässigkeit fällt dabei zum Beispiel, dass:

• das Endgerät nicht mit einer Zugangssperre (PIN) versehen ist,
• oder die PIN des Endgeräts bzw. der App zusammen mit der Kreditkarte oder dem Endgerät aufbewahrt wird.

Die Beweislast, dass grobe Fahrlässigkeit vorliegt, liegt in diesem Fall bei der Bank.

Mein persönliches Fazit

Die DKB hat zeitnah auf meine Fragen reagiert und diese zu meiner Zufriedenheit beantwortet. Dies empfinde ich als positiv.

Dass die Nutzung freier bzw. alternativer Betriebssysteme quasi ausgeschlossen ist, da bei Jailbreak oder Rooting die Haftung komplett ausgeschlossen wird, bedaure ich. Da man mit einem Jailbreak bzw. Rooting jedoch elementare Sicherheitsmechanismen umgehen kann, kann ich den Haftungsausschluss an dieser Stelle nachvollziehen.

Ich selbst habe mein Telefon nun wieder mit einer PIN versehen und meine Kreditkarte registriert.

Ob es bei SecureCode für Mastercard genauso aussieht, kann ich noch nicht sagen. Sobald ich die Bedingungen hierfür gefunden, studiert und eventuelle Fragen geklärt habe, werde ich diesen Artikel aktualisieren.

Quellen und weiterführende Links

[1] Wikipedia: 3-D Secure
[2] Sonderbedingungen für das 3D Secure-Verfahren bei Internet-Zahlungen mit der DKB-Kreditkarte
[3] smsTAN vs. pushTAN vs. chipTAN

Bild von TheDigitalArtist via pixabay / Lizenz: CC0 Public Domain

Sicherheit ist genau so wie Privacy Protection mittlerweile in nahezu jeder Ankündigung, Produktvorstellung oder Updatemeldung zu finden. Die Firmen bedienen damit ein Bedürfnis nach gefühlter Sicherheit unter den Kunden und Dienstnutzern. Doch "Sicherheit" ist kein feststehender Begriff und oftmals äußerst schwammig formuliert. Teilweise gewinnt man den Eindruck Firmen wollen den technisch unbedarften Anwender gezielt in die Irre führen um ihre Dienste populärer zu machen.

Keine definierten Begriffe

Die bekanntesten Beispiele für dieses Vorgehen sind sicherlich die sozialen Netzwerke. Datenschutz meint hier in der Regel keine Datensparsamkeit, die in den meisten europäischen Gesellschaften noch immer dem Datenschutz-Konzept zu Grunde liegt, sondern die Möglichkeit die öffentliche Sichtbarkeit zu steuern. Frei nach dem Motto "Was der Staat oder der Dienstanbieter weiß ist kein Problem, Hauptsache die Nachbarn wissen es nicht".

Deutlich extremer betrieb in den vergangenen Monaten Google dieses Sicherheitsmarketing. Google versucht sich schon seit längerem an einer Charme-Offensive im europäischen Raum, was vermutlich auch an den laufenden EU-Verfahren gegen den Konzern liegt. Die Quasi-Monopolisten aus Kalifornien werden langsam mit normalen wirtschaftspolitischen Maßstäben gemessen und reguliert, weshalb diese nun versuchen nun global staatliche Maßnahmen zu abzuschwächen. Sowas nennt sich halt Lobbyarbeit. In Demokratien ist es dafür nicht schlecht, wenn die Bevölkerung meint, man gehöre zu "den Guten".

Hier ist hilfreich, dass zwar viele Menschen "Sicherheit" und "Datenschutz" gut finden. Die wenigsten aber diese Begriffe wirklich definieren und somit leere Marketinghülsen als solche entlarven können.

Produktankündigungen ohne kritische Presse

Im konkreten Fall verspricht z. B. Google man entwickle "ein neues Gmail". Hier bewirbt man neben Phishing-Schutzmaßnahmen auch vertrauliche E-Mails mit Ablaufdaten und Widerruf. Sowie der Möglichkeit E-Mail Funktionen wie Weiterleiten, Kopieren, Herunterladen etc. zu deaktivieren. Klingt alles ziemlich gut und viele IT-Medien gaben die Pressemitteilung ziemlich kritiklos wieder. Zum Glück bezahlten manche Seiten noch Redakteure für kritische Berichterstattung.

Die E-Mail ist ein standardisiertes Protokoll und wirkliche Veränderungen auf Protokollebene sind folglich ein langwieriger Abstimmungsprozess. Man muss kein Experte sein um das zu wissen. Viele dieser Funktionen werden folglich nur zur Verfügung stehen, wenn man sich ausschließlich innerhalb des GMail-Systems bewegt. Sowohl Empfänger, als auch Absender müssen GMail verwenden um diese Funktionen zu nutzen. Das hebelt einen entscheidenden Vorteil des E-Mail Systems aus: Die Dezentralität. GMail ist sehr erfolgreich, Ausflüge Googles in den Messenger-Bereich waren dies eher nicht. Vielleicht möchte man nun den sehr erfolgreichen Dienst zum Sprungbrett für ein geschlossenes Kommunikationssystem machen, bei dem man eben auch noch nach außen schreiben kann - mit abgespeckten Funktionen.

Gleichwohl ist Sicherheit hier auch wieder in der oben genannten Definition zu verstehen. "Sicher" ist wenn ich verhindern kann, dass der Empfänger meine Nachricht beliebig vervielfältigt, "sicher" ist wenn ich vor Phishing geschützt bin. Ende-zu-Ende Verschlüsselung kommt nicht vor. Auch E-Mails mit Ablaufdatum und Vervielfältigungsschutz werden für Google ein offenes Buch sein - auch wenn man inzwischen das scannen für Werbezwecke eingestellt hat.

Ein anderes Beispiel ist Chrome. Hier präsentiert man sich als Vorreiter für ein sicheres Web und beginnt nun im Sommer aktiv damit Seiten ohne HTTPS-Verbindung zu bestrafen. Eine durchgehende HTTPS-Verschlüsselung des Netzes wäre zwar wünschenswert, ändern aber nichts daran, dass HTTPS nichts am hemmungslosen Nutzertracking ändert. Ein Bereich in dem Google als Werbefirma führend ist, es gibt schließlich gute Gründe Google als Datenkrake zu bezeichnen.

Der kürzlich lancierte integrierte Werbeblocker in Chrome soll wohl dementsprechend auch eher dazu führen, dass der Werbemarkt konsolidiert wird und weniger Anwender Blocker nutzen, die auch Google-Werbung blockieren.

Open Source Verflechtungen

Besonders prekär ist diese Marketing-Strategie im Open Source-Bereich. Open Source-Software bzw. quelloffene Entwicklung sind extrem positiv besetzt. In einer Gesellschaft die nach Transparenz strebt hört sich das einfach gut an. Dem gegenüber stehen geschlossene Firmen wie Apple oder Microsoft, die bestenfalls den Ruf haben einen goldenen Käfig zu errichten und schlimmstenfalls als dunkle Monopolisten erscheinen, die wie Kraken Staaten korrumpieren und ihre Dienste durchsetzen. (siehe z.B. die Resonanz auf die ARD Dokumentation "Das Microsoft Dilemma" oder die Berichterstattung zu Lizenzkosten des Bundes)

Viel zu wenig Beachtung finden Abhängigkeiten in der Open Source-Entwicklung. Hier haben Firmen wie beispielsweise Google ein enges Netz von Abhängigkeiten errichtet. Erstens hat man es geschafft, dass man als Open Source-Unternehmen wahrgenommen wird. Produkte wie Android und Chrome respektive Chromium sind ja quelloffen, der zweite Satz auf Wikipedia zu Chrome bezieht sich z. B. darauf.. Die ganzen proprietären Apps und nicht freien Teile finden kaum Beachtung. Zweitens hat man durch Sponsoring wie den Google Summer of Code ein ungutes Abhängigkeitsverhältnis vieler Open Source-Projekte geschaffen. Man sponsert Projekte, finanziert Sicherheitsüberprüfungen, unterstützt mit viel Geld den Hauptkonkurrenten auf dem Browsermarkt Mozilla. etc. pp.

Viele Open Source-Projekte stehen daher Google Diensten viel zu unkritisch gegenüber. Die starke Einbindung von Google Produkten wie der Engine Blink, Chromium in Distributionen, Google als Standardsuche usw. usf. sprechen da Bände.

Plan? Wohl eher nicht

Sind die IT-Giganten im Silicon Valley nun alle böse? Nein ganz bestimmt nicht. Die großen IT-Firmen haben keinen dunklen Plan zur Weltherrschaft oder arbeiten alle für böse Geheimdienste. Solche Verschwörungstheorien sind quatsch.

Die Firmen haben aber erkannt, dass man ein gutes Image braucht um erfolgreich zu sein und sein Geschäftsmodell zu behaupten. Man kann schließlich sehen, wie schwer es werden kann sich am Markt zu behaupten, wenn man erst einmal - wie beispielsweise Microsoft - ein eher zweifelhaftes Bild in der Öffentlichkeit hat. Wenn das eigene Geschäftsmodell auf Werbung und der damit zusammenhängen massenhaften Auswertung von Benutzerdaten beruht, dann sollte man dafür sorgen, dass der Gesetzgeber in den wichtigen Märkten hier nicht zu stark regulierend eingreift.

Um das zu erreichen tut man so, als ob einem die Sicherheit des Internets am Herzen liegt. Man tut natürlich auch etwas für die Sicherheit, z. B. für den Schutz vor illegalen Angriffen und anderen Bedrohungen. Allerdings hat man auch nichts dagegen, wenn der Kunde davon ausgehend stillschweigend davon ausgeht, dass man etwas für die Datensicherheit tut.

Die Open Source-Gemeinschaft sollte jedenfalls aufpassen, dass sie ihre Unabhängigkeit hier nicht zusehends verliert. Tabakfirmen sponsern manchmal auch Nichtraucherkampagnen. Demnächst sollen ja auch dann auch Linux-Apps auf ChromeOS laufen.