Mozilla arbeitet an einer neuen Fähigkeit für Firefox, um mit mehreren Tabs gleichzeitig interagieren zu können.

Bislang kann immer nur maximal ein Tab gleichzeitig verschoben oder geschlossen werden. Mozilla arbeitet an einer neuen Fähigkeit für Firefox, welche es erlaubt, mit mehreren Tabs gleichzeitig zu interagieren.

Dies funktioniert, indem der Nutzer bei gedrückter Strg-Taste (macOS: Cmd-Taste) mehrere Tabs markieren und dann per Kontextmenü-Eintrag die gewünschte Aktion ausführen kann. Mittels gedrückter Shift-Taste soll eine ganze Reihe von Tabs ausgewählt werden können. Ein Kontextmenü-Eintrag erlaubt die Markierung aller geöffneten Tabs.

Alles, was bisher für einen Tab möglich war, soll in Zukunft auch für mehrere Tabs möglich sein. Neben der bisher bekannten Möglichkeit, einen einzelnen Tab in ein neues Fenster zu verschieben, sollen die Möglichkeiten neu dazu kommen, den Tab ganz an den Anfang oder das Ende des aktuellen Fensters zu verschieben. Zu den Optionen, andere Tabs oder die Tabs rechts vom ausgewählten Tab zu schließen, soll die Option dazu kommen, doppelte Tabs zu schließen.

Die Schaltfläche, welche derzeit erscheint, wenn der Anwender mehr Tabs offen hat als auf dem Bildschirm Platz haben, und bei Klick alle geöffneten Tabs anzeigt, soll in Zukunft permanent sichtbar sein, also auch bei wenigen geöffneten Tabs. Hier sollen Funktionen zugänglich gemacht werden, welche alle geöffneten Tabs betreffen, z.B. alle geöffneten Tabs stumm schalten oder alle geöffneten Tabs als Lesezeichen hinzufügen.

Die Entwicklung findet hinter der in about:config vorhandenen und standardmäßig deaktivierten Einstellung browser.tabs.multiselect statt. Derzeit passiert noch nicht mehr, als dass der Tab-Text bei Mehrfachauswahl fett wird. Aber das wird sich in den kommenden Monaten ändern.

Der Beitrag Firefox bekommt Multi-Tab-Management erschien zuerst auf soeren-hentzschel.at.

In knapp 2 Wochen ist es soweit, denn am 25.05.2018 tritt die Datenschutz-Grundverordnung (DSGVO) in Kraft.
Ich habe mich nun auch mal damit auseinandergesetzt und aus den ganzen Aenderungen Konsequenzen gezogen:

• Alle iframes entfernt (YouTube, Vimeo, GitHub, Twitter, …) und durch Links ersetzt
• Unter Datenschutz ein bisschen ausfuehrlicher beschrieben, was ich speichere
• Meine Content Security Policy (CSP) angepasst (u.a. mit Hilfe des CSP Evaluators von Google und ReportURI)
• Den Header Referrer-Policy von no-referrer-when-downgrade zu strict-origin-when-cross-origin geaendert (Erklaerung)

Damit ist meine Website noch ein bisschen schneller und datenschutzfreundlicher geworden und ihr koennt nun selbst entscheiden, ob ihr euch das Verlinkte ansehen wollt oder nicht.
Da ja nun auch keine externen Videos mehr eingebunden werden, koennen diese trotzdem recht datenschutzfreundlich angeguckt werden, z.B. mit youtube-dl.

Es steht allerdings noch die Anpassung/Anonymisierung der IP-Speicherung durch Nginx aus.
Allerdings bin ich mir hier noch nicht sicher, ob und wie ich diese durchfuehre.

Fuer alle, die etwas mehr einsetzen als ich (z.B. Cookies), gibt es hier ein paar Links (auch die weiteren Links beachten!):

• https://github.com/lukasleitsch/dsgvo-checkliste
• https://www.unixe.de/unixe-dsgvo/

Interessant ist in dem Zusammenhang das Tool Webbkoll, was eine URL auf diverse Dinge, z.B. TLS, Referrer, Cookies, CSP und Third-parties testet.

Angestiftet durch den Hinweis “Referrers partially leaked” hatte ich kurzzeitig die Policy auf no-referrer gesetzt, mich dann aber doch wieder umentschieden, da so fremde Websites nicht einsehen koennen, dass Leute von mir kommen, was ich dann zwecks Bekanntheitsgrad vermeiden moechte. (Convince me otherwise!)

LXD ist ein Hypervisor für Linuxcontainer, den es seit einigen Versionen in Ubuntu gibt. Ein Linuxcontainer ist im Prinzip wie eine virtuelle Maschine, nur leichtgewichtiger. Wir verwenden LXD / LXC für viele unserer Anwendungen an der Schule. LXD lässt sich leicht bedienen und es gibt so einige Gründe, warum wir es verwenden. Heute möchte ich zeigen, wie man das Backup für LXD-Container machen kann.

1. Möglichkeit: lxc copy

Die einfachste Möglichkeit besteht darin, das man einen LXD-Container einfach auf einen anderen Rechner kopiert. Dazu braucht man einen zweiten LXD-Host, den man auf dem ersten als Remote hinzufügt.

$ sudo lxc remote add lxd2 192.168.1.50

lxd2 ist dabei der Name, den man dem zweiten LXD-Host geben wollen, gefolgt von der IP. Beim Setup des zweiten LXD-Hosts muss man darauf achten, dass er über das Netzwerk erreichbar ist und man muss auch ein Admin-Passwort vergeben. Dieses Passwort muss man eingeben, wenn man die Remote hinzufügen will.

Ist alles eingerichtet kann man sich z.B. alle Container auf der Remote anzeigen lassen:

$ lxc list lxd2:

Um nun ein Backup eines Containers zu machen, kopiert man ihn bzw. einen Snapshot auf die eben hinzugefügte Remote:

$ lxc snapshot my-container my-snapshot
$ lxc copy my-container/my-snapshot lxd2:my-backup

In umgekehrter Weise kann man den Container wieder auf dem ursprünglichen Host wiederherstellen.

$ lxc copy lxd2:my-backup my-container-restored

2. Möglichkeit: lxc export und lxc publish

Mit LXD kann man auch einen Container als komprimiertes Image exportieren und dann auf einem NAS, einem Offsite-Backup oder einem Cloud-Speicher sichern. Später können diese Images dann mit lxc import wieder importiert bzw. wiederherstellt werden.

Auf Github habe ich ein Skript gefunden, welches genau unsere Anforderungen erfüllt. Es exportiert den gewünschten Container und sichert ihn dann mit rclone (tolles Projekt!!!) auf einen Cloud-Speicher/NAS unserer Wahl.

Dazu muss man sich erst noch rclone installieren und einrichten. Ein Anleitung für die Installation und Pakete für alle Plattformen gibt auf der Projektwebseite. rclone unterstützt so ziemlich jeden Cloud-Speicher und Protokoll (ssh, webdav, …). Wir haben uns für ein Backup auf Google Drive entschieden, da wir da durch GSuite for Education unbegrenzten Speicherplatz haben 🙂

Ist rclone eingerichtet lädt man sich das Backup-Skript herunter, macht es ausführbar:

$ wget https://raw.githubusercontent.com/cloudrkt/lxdbackup/master/lxdbackup
$ chmod +x lxdbackup

Damit der Upload des Backups auch funktioniert muss man noch einige Parameter festlegen (v.a. RCLONETARGET).

$ nano lxdbackup
# Settings

# The target bucket or container in your Rclone cloudstorage 
RCLONETARGETDIR="lxdbackup" 
# Optional Rclone settings.
RCLONEOPTIONS=""
# Rclone target cloud used in your rlcone.conf
RCLONETARGET="my-remote"
# Directory were local images are stored before upload
WORKDIR="/tmp/lxdbackup"

Nun kann man das Skript mit folgendem Aufruf testen:

$ lxdbackup my-container

Wenn alles gut geht, sollten man sein Backup nach einiger Zeit (der Export eines Containers kann etwas dauern, je nach Größe) auf dem Speichern finden, den man in rclone konfiguriert hat.

Fazit

Bisher haben wir einfach den LXD-Host im Gesamten gesichert. Das reicht in der Regel aus, aber man verliert die Möglichkeit einzelne Container getrennt voneinander wiederherstellen zu können. Mit dem lxdbackup-Skript und der Kombination mit rclone haben wir nun viel mehr Möglichkeiten und können unsere Container sehr flexibel sichern. Mit Hilfe von Cronjobs haben wir das Backup automatisiert. Manche Container werden z.B. 2x am Tag gesichert, andere nur 1x in der Woche (und das nur, wenn keine Schulferien sind) – je nach Anwendungsfall.

2 Kommentare

Der Beitrag Backup für LXD-Container erschien zuerst auf .:zefanjas:..

Wie ich in meinem Blog irgendwann mal erwähnt habe, studiere ich im Moment Bioinformatik an der THM und JLU in Gießen. Da ich nebenbei auch  noch einen Job in einer der Arbeitsgruppen habe, bekomme ich einen Recht guten Eindruck davon, was aktuell Forschungsgebiet in der Bioinformatik ist und vor allem welche Software und Hardware dort eingesetzt wird. Einen Überblick über beispielsweise die Hardware des Bioinformatikfachbereichs an der THM liefert der z.B. folgende Link:

mni.thm.de: Bioinformatik erweitert Infrastruktur

Ubuntu ist im Bioinformatik-Umfeld sehr weit verbreitet. Ich würde sogar sagen, dass knapp 80% aller Bioinformatiker Ubuntu (Mit verschiedenen Desktops) einsetzen. Der Rest verteilt sich auf Debian und Arch-Linux. Es gibt auch Windows-Nutzer, aber diese sind deutlich in der Unterzahl. Ein sehr nettes Feature seitens Ubuntu und Debian ist die Tatsache, dass nahezu alle wichtigen Bioinformatik-Tools direkt in den Paketquellen vorhanden sind. Das ist auch einer der Hauptgründe für die weite Verbreitung.

Die Bioinformatik ist grundsätzlich sehr Unix-affin. Nahezu alle Server, die irgendwas mit Bioinformatik und verwandten Gebieten zu tun haben, laufen unter einem Unix-System (Heutzutage hauptsächlich eine Linux-Distribution). Und wer tagtäglich auf einem Unix-System unterwegs ist, arbeitet auch privat eher mit so einem System.

Das Projekt, welches die Bioinformatik als eigenständiges Fachgebiet der Informatik etabliert hat, war das „Humangenomeprojekt„. Dieses Projekt lief von 1990 bis ca. 2003 und endete mit der fast vollständigen Sequenzierung (Dem Ablesen des DNA-Strangs) und der Assemblierung (Dem Zusammenpuzzlen von DNA-Schnipseln) eines menschlichen Genoms. Die Gesamtkosten des Projekts lagen dabei bei ca. 3 Mrd. US-Dollar. Ohne den massiven Einsatz von leistungsstarken Computern und den passenden Algorithmen, hätte diese Aufgabe wahrscheinlich noch Jahrzehnte gedauert. Ich gehe jetzt hier nicht zu sehr ins Detail, eine gute Übersicht bietet z.B. der englische Wikipedia-Artikel „Sequence Assembly“

Quelle: http://www.genomicglossaries.com/presentation/SLAgenomics.asp

Anfang bis Ende der 90er Jahre des letzten Jahrtausends war „leistungsstarker Computer“ ein Synonym für Unix-basierte Server und Workstations mit RISC-CPUs (z.B. von SUN, Silicon Graphics, IBM, HP, usw.). Wer große Datenmengen verarbeiten wollte, musste ein Unix-System benutzen. Das lag vor allem an drei Dingen:

1. Unix war schon damals technisch ausgereift und stabil. Windows hingegen war mit der ersten NT-Version 3.0 und später mit NT 4.0 gerade erst den „Kinderschuhen“ entwachsen, aber noch weit davon entfernt Unix ein ernsthafter Konkurrent zu sein.
2. x86-basierte Rechner waren damals einfach noch nicht leistungsfähig genug, um die gewaltigen Datenmengen, welche in der Bioinformatik anfallen, verarbeiten zu können und auch die Hardware war noch nicht stabil genug um tage -oder wochenlang am Stück zu laufen. Während dauerlaufende Multi-Core-Server mit mehr als 4 CPUs in der Unix-Welt eine alltägliche Sache waren, dauerte es in der x86-Welt bis in die frühen 2000er Jahre bis es zuverlässige Server in dieser Größenordnung gab.
3. Alle Kommandozeilentools unter Unix machen Gebrauch von dem Umleiten von Datenströmen und nahezu jedes bioinformatische Programme macht ebenfalls davon Gebrauch. Oft reicht es mehrere Programme mittels der Pipe miteinander zu verbinden um die gewünschten Daten zu erhalten.

Der zweite Punkt änderte sich zwar im Laufe der 2000er Jahre, aber Windows ist im Bereich des „High Performance Computings“ (HPC) nie wirklich angekommen (Seit November 2017 besteht die Top 500 der Supercomputer nur noch aus Linux-basierten Systemen). Das lag und liegt vor allem daran, dass ein Bioinformatiker im Grunde „nur“ gigantisch große Textdateien analysiert und Unix durch seine vielen kleinen Tools dafür prädestiniert ist. Für einen Bioinformatiker ist es vollkommen normal eine 20 GB große Datei mit „grep“, „awk“ und Co zu behandeln. Dazu kommt der Fakt, dass es bis heute relativ umständlich ist Windows über Fernwartungstools zu bedienen. Erst letztes Jahr hat sich Microsoft dazu durchgerungen Windows mit einem SSH-Server -und Client auszuliefern. Selbst Microsoft hat in der Zwischenzeit bemerkt, dass eine komfortable und mächtige Shell unabdingbar ist.

Um ein Gefühl für die Datenmengen, die einem als Bioinformatiker tagtäglich einfach mal so begegnen können, zu bekommen, hier ein Beispiel aus meinem Studium:

Ich habe meine Bachelorarbeit über das Themengebiet „ChIP-Seq“ geschrieben. Mit Hilfe von ChIP-Seq kann man Bindestellen von Proteinen mit der DNA feststellen. Diese sind wichtig um festzustellen wo z.B. ein bestimmtes Gen auf der DNA liegt bzw. wo dessen Beginn ist. Um zuverlässig diese Bindestellen zu finden, muss man mehrere Experimente im „Wet-Lab“ durchführen, welche am Ende sehr große Datenmengen erzeugen. In meinem Ordner auf dem NAS meiner Arbeitsgruppe liegen aktuell 164 GB an Daten. Es sind sogar noch ein paar GB mehr, da das NAS ZFS benutzt und die Dateikompression aktiviert ist und sich Textdateien gut komprimieren lassen. Mein Kommilitone schreibt gerade eine Pipeline zur Verarbeitung von Gendaten. Er meinte er knackt noch den Rekord der Arbeitsgruppe, der bei ca. 8 TB liegt.

Die Rohdaten aus den ChIP-Seq-Experimenten müssen erst mit Hilfe eines sogenannten „Aligners“ auf das menschliche Genom gemappt werden. Das heißt grob, man schaut wo jeder einzelne der sogenannten „Reads“ (Ein kleiner DNA-Schnipsel mit ca. 50-1000 Buchstaben Länge, je nach eingesetzer Sequenzierungstechnologie) auf dem Genom liegt (Welches bei Menschen ca. drei Mrd. Buchstaben lang ist). Da die Rohdaten aus ungefähr 50 Mio. Reads pro Datei bestehen, dauert das ein wenig (In der Regel einen Kaffee). Moderne Aligner wie z.B. Bowtie2 unterstützen deshalb Multithreading um das Mapping zu beschleunigen.

Damit das Mappen schnell durchläuft, habe ich das Programm auf einem Server mit 64 Kernen (128 Threads) und 2 TB RAM laufen lassen. Der Aligner lief dabei nicht auf allen Kernen, da dieser ab 16 Threads nicht linear skaliert (Das liegt weniger am Programm, sondern daran, dass sich die 64 Kerne auf 4 CPUs verteilen und die Kommunikation zwischen diesen einiges an Leistung frisst). Aus diesem Grund habe ich maximal zwei Aligner mit 16 Threads parallel laufen lassen (Ich benutze nur 32 Kerne, da auch andere Benutzer den Server benutzen wollen).

Für Bioinformatiker ist das Buzzword „Big Data“ also nicht nur eine leere Worthülse, sondern Alltag. Im Grunde können wir nur darüber lächeln, wenn ein Wirtschaftsinformatiker bei einer Datenbank mit knapp 10 GB Dateigröße über die Datenmenge stöhnt. Natürlich kann man die Art der Daten nicht miteinander vergleichen (Bioinformatische Datenbanken haben in der Regel nur wenige Relationen), aber das obige Beispiel ist gerade mal die Spitze des Eisberges. Bei größeren Analysen oder dem relativ neuen Feld der Metagenomik (Salopp erklärt: Man nimmt einen Löffel mit Dreck und schaut was darin an Leben enthalten ist.) können leicht mehrere Petabytes (1 PB = 1000 TB) an Daten zusammenkommen, die einen Rechencluster mit mehreren hundert CPUs wochenlang mit der Analyse beschäftigen können.

Neben konventionellen CPUs kommen auch immer mehr GPUs zum Einsatz. Diese eignen sich besonders zum Training von großen neuronalen Netzwerken (Deep Learning) welche z.B. darauf trainiert werden Unregelmäßigkeiten in Langzeit-EKGs festzustellen oder Tumorzellen in Zellgewebeschnitten zu erkennen und zu klassifizieren. Gerade Letzteres basiert heute noch sehr auf der subjektiven Meinung eines Onkologen und nicht auf objektiven Maßstäben (Zeigt man einen solchen Zellschnitt drei verschiedenen Onkologen, erhält man in der Regel drei verschiedene Diagnosen). Software auf Basis neuronaler Netzwerke soll dabei den Arzt nicht ersetzen, sondern ihn bei seiner Arbeit unterstützen und vor allem entlasten. Das letzte Wort soll dabei immer noch ein Arzt haben. Das Training von großen Netzen kann mehrere Tage bis Wochen in Anspruch nehmen, weshalb momentan immer mehr dezidierte Hardware zum Beschleunigen dieses Trainings auf den Markt kommt. Die THM hat z.B. Anfang des Jahres eine Nvidia DGX-1 mit 8 Tesla V100 angeschafft. Diese läuft unter einer angepassten Version von Ubuntu 16.04 (Um den Bogen zu Linux zu spannen).

Die Hauptarbeit eines Bioinformatikers besteht in der Datenanalyse:

Biologen liefern die Daten und die Bioinformatiker der Arbeitsgruppe analysieren diese unter den gewünschten Gesichtspunkten. Dazu gehört der Einsatz schon vorhandener Tools wie z.B. Bowtie(2), SAMtools, Velvet, BioPython, R, usw. Die Liste lässt sich schier endlos weiterführen.

Falls kein Tool vorhanden ist, muss oft ein neues implementiert werden um z.B. einen speziellen Sachverhalt zu untersuchen. Die allermeisten Tools werden dabei in C, Java, Python oder R geschrieben, wobei Python und R am häufigsten benutzt werden (Ich schreibe meine Programme meistens in Python). Programme, bei denen es auch auf Geschwindigkeit ankommt, werden in C oder C++ entwickelt, wobei sehr häufig die Sprachen bunt gemischt werden (z.B. der kritische Teil in C, der Rest in Python oder R). Die Entwicklung findet dabei, aus den oben genannten Gründen, primär unter Linux statt. Der Trend geht dabei eindeutig zu webbasierten Anwendungen, um den Anwendern die Installation und Konfiguration abzunehmen und vor allem eine leistungsfähige Hardware zur Verfügung zu stellen.

Ein wichtiges, wenn nicht das wichtigste Teilgebiet der Bioinformatik ist die Entwicklung neuer Algorithmen um bestimmte Aufgabenstellungen effizienter und schneller als vorher zu erledigen. So war es z.B. erst durch die Entwicklung von bestimmten Algorithmen möglich das Humangenomprojekt schneller als geplant abzuschließen. Ich will jetzt hier nicht allzu sehr ins Detail gehen, sondern nenne nur eine kleine Liste wichtiger Algorithmen und Datenstrukturen:

• BLAST zur schnellen Suche von Gensequenzen in großen Datenbanken.
• Needleman-Wunsch und Smith-Waterman zur exakten Suche von Strings in Texten.
• Suffixbäume und Suffixarrays zur schnellen Suche in Texten.
• Die Burrows-Wheeler-Transformation (BWT) zur Datenkompression (bzip2) und auch als Grundlage für eine Alignment-Software namens BWA.
• Der Ferragina-Manzini-Index zur Indexierung großer Textdateien.
• De Bruijn-Graphen für das Assemblieren von Genomen.

Die Liste ist bei Weitem nicht vollständig, deckt aber die Dinge ab, die mir während meines Studiums nahezu tagtäglich im Rahmen von Vorlesungen, Hausübungen und Projekten begegnet sind. Gerade die BWT begegnet einem Linux-Benutzer in Form von bzip2 nahezu alltäglich.

Die immer größeren Datenmengen, welche durch die Einführung der „Next Generation Sequencing„-Technologien produziert werden, können nicht alleine durch die Anschaffung besserer Computer und Server schneller bearbeitet werden. Wie stark die Entwicklung der „NGS“-Technik die Kosten reduziert und damit auch die Arbeit der Biologen verändert hat, kann man z.B. an der folgenden Grafik sehen:

Quelle: https://www.genome.gov/27565109/the-cost-of-sequencing-a-human-genome/

Die Y-Achse der Grafik ist logarithmisch aufgetragen, d.h. jeder Strich ist um den Faktor 10 größer. Wie oben schon erwähnt kostete das Human Genom Projekt ca. 3 Mrd. US-Dollar. Rechnet man nur die reinen Kosten für die Sequenzierung, waren es „nur“ 300 Mio. US-Dollar. Das war ungefähr im Jahr 2002. Heute kostet die vollständige Sequenzierung eines menschlichen Genoms in etwa 1500 US-Dollar. Die Assemblierung des Genoms lässt sich heute fast auf einem Desktop-PC in akzeptabler Zeit bewerkstelligen. Ein kleiner Server mit 16 Kernen und 32 GB RAM reicht je nach Programm vollkommen aus und schafft die Assemblierung dann in weniger als einem Tag. Die Sequenzierung von kleinen Bakteriengenomen kostet nur wenig mehr als 100$ und die Assemblierung ist in wenigen Minuten auf einem heutigen Standardlaptop erledigt. Mit der Einführung der Nanopore-Technologie und Sequenziergeräten in Größe eines USB-Sticks, welche gerade mal 1000$ kosten, wird die Datenmenge noch weiter zunehmen.

Ich könnte den Artikel an dieser Stelle noch weiter ausbauen, aber das Gebiet der Bioinformatik ist so groß (z.B. habe ich das Gebiet des „Molecular Modellings“ oder der Proteinstrukturvorhersage und andere Themen komplett ausgeklammert), dass ich irgendwo aufhören musste um nicht den Rahmen zu sprengen. Ich hoffe aber das der Artikel einen kleinen Einblick in das Thema gegeben hat und dass Linux gerade in der Forschung unabdingbar geworden ist.

Mozilla hat Firefox 60 veröffentlicht. Auch Firefox 60 bringt wieder viele Neuerungen. Dieser Artikel fast die wichtigsten Neuerungen zusammen.

Download Mozilla Firefox 60.0 für Microsoft Windows, Apple macOS und Linux

Mehr Sicherheit für Firefox-Nutzer

Geschlossene Sicherheitslücken

Auch in Firefox 60 hat Mozilla wieder zahlreiche Sicherheitslücken geschlossen, worunter auch einige sind, welche von Mozilla als besonders kritisch eingestuft werden. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 60 daher für alle Nutzer dringend empfohlen.

Unterstützung für Web Authentication API

Firefox ist der erste Browser am Markt, der den neuen Web Authentication API-Standard, oder kurz: WebAuthn, zur sicheren Authentifizierung auf Webseiten ohne Eingabe eines Passworts, zum Beispiel über YubiKey, ermöglicht.

Unterstützung von Same-Site-Cookies

Firefox 60 unterstützt Same-Site-Cookies als Maßnahme gegen sogenanntes Cross-Origin Request Forgery (CSRF). Details hierzu liefert Mozillas Security-Blog.

Keine Unterstützung alter Symantec-Zertifikate mehr

Firefox akzeptiert keine Symantec-Zertifikate mehr, welche vor dem 01.06.2016 ausgestellt worden sind. Ab Firefox 63 wird Firefox überhaupt keine Symantec-Zertifikate mehr akzeptieren. Dies betrifft ebenfalls die zu Symantec gehörenden CAs Thawte, VeriSign, Equifax, GeoTrust sowie RapidSSL. Symantec hatte aufgrund verschiedener Vorfälle das Vertrauen der Browserhersteller verloren.

Verbesserungen für die Startseite / den neuen Tab

Die Seite, die standardmäßig als Startseite eingestellt ist und auch beim Öffnen eines neuen Tabs erscheint, hat diverse Verbesserungen erhalten. So wurde das Layout angepasst, um auf großen Bildschirmen mehr Inhalt anzeigen zu können.

Die verschiedenen Bereiche konnten bereits entweder eingeklappt oder komplett deaktiviert werden. Ab sofort ist es auch möglich, die Reihenfolge beliebig anzupassen.

Der Bereich „Überblick“ beinhaltet eine Auswahl von Webseiten, welche kürzlich besucht oder als Lesezeichen gespeichert worden sind. Hier werden standardmäßig zusätzlich nun auch Webseiten angezeigt, die der Nutzer über die entsprechende Schaltfläche in Firefox bei Pocket abgelegt hat, einem Online-Dienst von Mozilla. Stichwort Pocket, für einen Teil der Nutzer in den USA werden im Pocket-Abschnitt jetzt auch gesponsorte Stories angezeigt.

Das Suchfeld der Startseite / des neuen Tabs zeigt jetzt auch das Logo der eingestellten Standard-Suchmaschine an, womit für den Nutzer klarer wird, dass darüber eine Suche bei der Suchmaschine seiner Wahl erfolgt. Auch der Text in der Adressleiste wurde angepasst und beinhaltet nun den Namen der eingestellten Suchmaschine.

Privatsphäre-Einstellungen überarbeitet

Die Einstellungen im Bereich „Datenschutz & Sicherheit“ wurden überarbeitet. So erhält der Nutzer nun direkten Zugriff auf die Einstellungen zur Akzeptanz von Cookies, ohne vorher erst einstellen zu müssen, dass Firefox eine Chronik nach benutzerdefinierten Einstellungen anlegen soll. Das macht diese Einstellungen leichter zugänglich und gibt dem Nutzer letztlich dadurch mehr Kontrolle.

Der neue Abschnitt „Cookies und Websitedaten“ fasst die eben erwähnten Cookie-Einstellungen sowie die vorherigen Abschnitte „Zwischengespeicherte Webinhalte“ und „Websitedaten“ zusammen und sorgt damit für weniger Verwirrung durch die vielen ähnlichen, aber doch unterschiedlichen Einstellungen. Gerade die Trennung von Technologien wie Cookies und Local Storage waren für viele Nutzer unklar.

Was in den neuen Einstellungen nicht mehr geht, ist ein Löschen einzelner Cookies einer Domain. Aber diese detaillierte Kontrolle steht nach wie vor über die Entwicklerwerkzeuge von Firefox zur Verfügung.

Position von Suchmaschinen-Vorschlägen plus Einstellung

Bei der Eingabe eines Begriffes in die Adressleiste zeigt Firefox nicht nur bereits besuchte Webseiten und Lesezeichen an, auch kann Firefox direkt Vorschläge der eingestellten Standard-Suchmaschine anzeigen, sofern diese das unterstützt. Bislang erschienen diese Suchmaschinen-Vorschläge immer am Ende. Für Profile, die mit Firefox 56 oder früher erstellt wurden, ändert sich daran auch nichts. Für Profile, die mit Firefox 57 oder neuer erstellt wurden, ändert sich die Reihenfolge und Suchmaschinen-Vorschläge werden als erstes angezeigt.

So oder so, in den Einstellungen von Firefox gibt es eine neue Option, so dass jeder das Verhalten konfigurieren kann, welches ihm am meisten zusagt.

Neue CSS-Engine stellt Firefox-Oberfläche dar

Seit Firefox 57 arbeitet in Firefox eine neue, in der Programmiersprache Rust geschriebene, CSS-Engine.

Wir haben einen regelrecht bahnbrechenden Ansatz entwickelt, um Webseiten zu gestalten – eine superschnelle CSS-Engine, die in Rust geschrieben ist (eine Systemprogrammiersprache, die von Mozilla unterstützt wird). Diese neue, in Firefox integrierte CSS-Engine arbeitet besonders schnell und unter Zuhilfenahme mehrerer Prozessorkerne zugleich. Das kann derzeit kein anderer Browser. – Mozilla

Die auf den Namen Stylo oder auch Quantum CSS hörende CSS-Engine wurde bislang nur für Webseiten eingesetzt. Ab Firefox 60 wird die neue CSS-Engine auch für die Darstellung der Firefox-Oberfläche selbst benutzt.

Tabs in Titelleiste auch für Linux

Für Nutzer von Windows und Apple macOS ist dies nicht neu: das Zeichnen von Tabs direkt in die Titelleiste anstelle der Anzeige des Webseiten-Titels in der Titelleiste. Mit Firefox 60 erhalten auch Linux-Nutzer diese Möglichkeit. Zu finden ist die Einstellung auf der Seite zur Anpassung der Firefox-Oberfläche, welche über das Firefox-Menü zu erreichen ist.

Verbesserungen für Entwickler von Firefox-Erweiterungen

Natürlich gab es auch für Entwickler von WebExtensions wieder einige neue APIs und Verbesserungen bestehender APIs. So werden nun viele neue Eigenschaften für Themes unterstützt, womit die Gestaltung von Firefox noch individueller erfolgen kann. Aber auch in Zusammenhang mit Tabs gibt es neue Möglichkeiten, Verbeserungen gab es bei der Proxy-API, Erweiterungen haben nun Zugriff auf den DNS-Service von Firefox, um Hostnamen aufzulösen. Sidebars können nun auch ihre Tastenkombination, falls vorhanden, in Firefox anzeigen. Mehrere Startseiten können WebExtensions nicht mehr setzen, sondern nur noch eine. WebExtensions können dem Nutzer jetzt die Möglichkeit anbieten, eine zuvor definierte (eigene) Tastenkombination zu ändern. Zahlreiche weitere Erweiterungen der WebExtension-Plattform werden hier beschrieben.

Verbesserungen der Webplattform

Natürlich gibt es auch bezüglich Webstandards wie immer auch in Firefox 60 Neuerungen. Hervorzuheben ist hier die Unterstützung von JavaScript-Modulen, von Array.prototype.values() und der CSS-Eigenschaft text-stroke. Die CSS-Eigenschaft transform wird nur noch ohne Vendor-Präfix -moz- unterstützt. Das Drücken der Enter-Taste in contenteditable-Elementen fügt nun ein „div“ anstelle eines „br“ ein. Weitere Informationen zu Änderungen für Webentwickler in Firefox 60 finden sich in den MDN web docs.

Neuerungen für Webentwickler

Das Regeln-Panel im Inspektor-Werkzeug kann nun auch CSS-Variablen vorschlagen. Der Tastaturbefehl zum Verändern von Zahlenwerten in 0,1-Schritten wurde auf Windows und Linux von Alt + Auf/Ab auf Strg  + Auf/Ab geändert, um ein Konflikt auf Betriebssystem-Ebene zu vermeiden.

Optionale Features

Einstellungen zum Abschalten von Sensor-APIs

Über Sensor-APIs können Webseiten Informationen über die Umgebung erhalten, in welcher ein Gerät genutzt wird. Mit den neuen Einstellungen device.sensors.proximity.enabled, device.sensors.ambientLight.enabled, device.sensors.orientation.enabled sowie device.sensors.motion.enabled können diese Sensor-APIs unabhängig voneinander durch Setzen per Doppelklick auf false deaktiviert werden. Die beiden erstgenannten Schalter wurden in Firefox 60 sogar bereits standardmäßig deaktiviert.

Neue Einstellungen für deutliche Warnung bei HTTP anstelle von HTTPS

Die verschlüsselte Übertragung von Daten wird immer mehr zu einem Muss im Web. In Firefox 60 stellt Mozilla zwei neue Einstellungen bereit, um relativ deutlich zu warnen, wenn eine Webseite über HTTP und nicht über HTTPS übertragen wird.

Wird security.insecure_connection_text.enabled via Doppelklick auf true gestellt, erscheint bei Webseiten, die nur über HTTP übertragen werden, der Schriftzug „Nicht sicher“ in der Adressleiste. Dies gilt sowohl für private als auch für nicht private Fenster. Außerdem kommt mit security.insecure_connection_text.pbmode.enabled noch eine zweite Einstellung dazu. Wird diese auf true gesetzt, dann erscheint dieser Schriftzug nur in privaten Fenstern.

Neue Einstellung zum Deaktivieren des FTP-Protokolls

In die gleiche Richtung zielt eine weitere neue Einstellung ab: auch über das FTP-Protokoll können Daten unverschlüsselt übertragen werden. Firefox 60 besitzt eine neue Einstellung, um das FTP-Protokoll vollständig in Firefox zu deaktivieren. Dafür muss network.ftp.enabled in about:config per Doppelklick auf false gesetzt werden.

Automatisches HTTPS-Upgrade für HTTP-Ressourcen

Und noch einmal geht es um das Thema HTTP und HTTPS: eine neue Einstellung erlaubt ein automatisches Upgrade von HTTP-Ressourcen auf HTTPS-Webseiten, sofern diese auch über HTTP verfügbar sind. Die Aktivierung erfolgt über den Schalter security.mixed_content.upgrade_display_content, welcher über about:config auf true geschaltet werden muss. Doch Achtung, dies kann auch dazu führen, dass ein Element auf einer Webseite überhaupt nicht mehr angezeigt wird. Die Funktionsweise wird ausführlich in diesem Artikel behandelt.

DNS over HTTPS

Firefox 60 bietet eine Unterstützung für DNS over HTTPS. Wie DNS over HTTPS konfiguriert werden kann, wird hier beschrieben. Die noch experimentelle Technologie soll die Sicherheit, Privatsphäre und Performance verbessern.

Neue Option zum Deaktivieren von Firefox Sync

Firefox besitzt eine Möglichkeit zur Synchronisation, womit es möglich ist, auf Chronik, Lesezeichen, Passwörter und mehr von verschiedenen Geräten aus zuzugreifen. Firefox 60 besitzt eine neue Option, um die den Zugang zu Sync komplett zu verbergen. Die entsprechende Option in about:config heißt identity.fxaccounts.enabled und muss dazu auf false gesetzt werden.

Eingabe in Adressleiste in einem neuen Tab öffnen

Firefox 60 besitzt eine neue Einstellung, um Eingaben in die Adressleiste in einem neuen Tab zu öffnen. Dazu muss über about:config der Schalter browser.urlbar.openintab per Doppelklick auf true geschaltet werden. Dies ergänzt ähnliche Einstellungen für das Suchfeld sowie für das Öffnen von Lesezeichen.

Neue Browserkonsole aktivieren

Nachdem die Webkonsole bereits in Firefox 57 ein komplett neues Frontend erhalten hat, welches nicht länger auf Mozillas proprietärem XUL-Standard basiert, sondern mit Webtechnologie umgesetzt worden ist, kann das neue Konsole-Frontend nun auch für die Browserkonsole aktiviert werden. Dazu muss über about:config der Schalter devtools.browserconsole.new-frontend-enabled auf true gesetzt werden.

Firefox 60 ist neue Basis für Firefox ESR

Firefox ESR ist die Firefox-Version mit Langzeitunterstützung und damit besser für Unternehmen und Organisationen geeignet ist, welche nicht alle sechs bis acht Wochen Neuerungen ausliefern können oder wollen. Firefox 60 stellt die neue Basis für Firefox ESR dar und löst damit Firefox ESR 52 ab. Auch wenn die Mainstream- und die ESR-Version von Firefox 60 im Großen und Ganzen gleich sind, gibt es doch ein paar Unterschiede zwischen beiden Versionen, welche in einem gesonderten Artikel beschrieben werden.

Firefox im Unternehmen konfigurieren

Gerade im Unternehmens-Umfeld kann es erwünscht sein, Firefox so zu konfigurieren, dass Bereiche wie die erweitere Konfiguration unter about:config oder der Add-on Manager für die Nutzer nicht zugänglich sind. Es könnte erwünscht sein, dass Features wie der integrierte PDF-Betrachter deaktiviert werden, eine besonder Startseite erscheint oder bestimmte Lesezeichen bereits standardmäßig vorhanden sind.

Diese und andere Dinge sind ab Firefox 60 möglich. Unter Windows kann dies über sogenannte Gruppenrichtlinienobjekte, kurz: GPO, erfolgen. Dabei handelt es sich um ein Feature von Windows, welches von Firefox ab Version 60 unterstützt wird. Die andere Möglichkeit ist über eine JSON-Konfiguration, welche im Distributions-Verzeichnis von Firefox abgelegt wird. Der Vorteil dieser Variante: es funktioniert nicht nur unter Windows, sondern ebenfalls unter Apple macOS sowie Linux.

Tipp: mit dem Enterprise Policy Generator wird in wenigen Tagen eine neue Erweiterung für Firefox veröffentlicht werden, welche die Erstellung einer solchen Konfigurations-Datei durch einfaches Zusammenklicken der gewünschten Optionen erlaubt.

Sonstige Neuerungen von Firefox 60

Mozilla hat die Audio-Performance von WebRTC für Linux-Nutzer verbessert. Ebenfalls WebRTC betrifft die folgende Änderung: Firefox deaktiviert ab sofort die Kamera und das Kamera-Lämpchen, wenn eine Video-Aufnahme gestoppt wird, und aktiviert beides wieder, wenn die Aufnahme fortgesetzt wird. So herrscht keine Unklarheit mehr darüber, ob die Kamera gerade etwas aufnimmt oder nicht.

Den bisher in C++ geschriebenen Parser, der all die Firefox-Einstellungen liest und verarbeitet, hat Mozilla in Rust neu geschrieben. Der neue Parser ist fast doppelt so schnell, sicherer, korrekter und besser wartbar als der alte Parser.

Kritische Bugfixes konnten seit Firefox 10 über sogenannte Hotfix-Erweiterungen ausgeliefert werden. Zuletzt wurde diese Infrastruktur nicht mehr genutzt, nachdem Mozilla immer mehr auf die sogenannten System-Erweiterungen setzt, welche diesen Anwendungsfall ebenfalls bedienen können. Mit Firefox 60 wurde die Unterstützung für Hotfix-Erweiterungen aus Firefox entfernt.

Das Standard-Favicon, welches für Webseiten ohne eigenes Favicon angezeigt wird, wurde geändert. Auf Windows wurde das Tastatur-Kommando zum Öffnen der Leseansicht einer Webseite auf F9 geändert.

Die about:config-Einstellung view_source.tab, um den Quelltext einer Webseite in einem eigenen Fenster statt in einem Tab anzuzeigen, wurde entfernt. Das Problem, dass unter Windows verschiedene Firefox-Prozesse bei den Lautstärke-Reglern erscheinen, konnte zwar nicht vollständig aus der Welt, aber deutlich verbessert werden.

Die Performance des Panels von WebExtensions, welche in dem sogenannten Überhangsmenü platziert werden, wurde spürbar verbessert. Verbessert wurde auch die Performance der Blockierlisten.

Der Beitrag Mozilla veröffentlicht Firefox 60 – die Neuerungen erschien zuerst auf soeren-hentzschel.at.

Schon vor einiger Zeit bin ich vom Gnome- zum Cinnamon Desktop gewechselt und bin mit der Entscheidung sehr zufrieden. Ich empfinde Cinnamon als optisch ansprechend, er ist umfangreich konfigurierbar und setzt nach wie vor auf das klassische Prinzip der Desktopbedienung. Längere Zeit nutzte ich Cinnamon mit Antergos als Distribution. Mittlerweile ist mir Stabilität und ein jederzeit einsatzbereites System wichtiger als aktuelle Software, weshalb ich derzeit bei Mint gelandet bin. Auch weil ich ein bisschen Heimweh nach der großen Ubuntu-Welt hatte.

Allerdings konnte ich mich nie mit Mints grünem Desktoptheme anfreunden. Und wie so oft sind es Kleinigkeiten, die mich wahnsinnig machen können und mit deren Änderung ich mich Stundenlang beschäftigen kann. Glücklicherweise lässt sich das “Problem” in diesem Fall einfach beheben. Die Farbe der Icons und Bedienelemente lässt sich problemlos über die Desktopthemen anpassen. Das Startmenü-Icon bleibt aber giftgrün, was zu einem unschönen und uneinheitlichen Erscheinungsbild des Desktops führt.

Aber auch das lässt sich ändern. Mit einem Rechtsklick auf das Icon des Startmenüs kann man den Dialog Einrichten öffnen. Hier lässt sich das Icon gegen eine beliebige Grafik austauschen. Man muss also nur die Standardgrafik (oder eine beliebige andere Grafik) nehmen, mit GIMP die Farbe ändern und anschließend den Pfad zur neu erstellten Datei angeben.

Damit hat der Desktop endlich wieder ein farblich einheitliches Erscheinungsbild.

Startmenü-Icon des Cinnamon Desktops ändern ist ein Beitrag von techgrube.de.

Ich habe seit Anfang des Jahres (Spätzünder 😁) einen RaspberryPi 3 dessen Backup ich nach der Einrichtung angefertigt habe indem ich die SD-Karte in den Rechner gesteckt und geklont habe. Natürlich möchte ich nicht immer den RaspberryPi herunterfahren um ein Backup mit dd¹ anzufertigen weshalb ich heute mal nach einer Lösung gesucht habe um das Remote zu erledigen. Wie sich herausstellte ist das ganze sehr einfach.

Auf dem RPi geben wir folgenden Befehl für unseren Benutzer zur Ausführung mit root-Rechten per sudo frei:

user ALL=(ALL) NOPASSWD: /bin/tar -cpO --exclude=/proc --exclude=/tmp --exclude=/mnt --exclude=/dev --exclude=/sys /

Statt user muss natürlich der Benutzer eingetragen werden mit dem man sich per SSH² auf dem Raspberry anmeldet und /dev/mmcblk0p2 muss gegebenfalls durch eure Bezeichnung der SD-Karte angepasst werden.

Danach kann das Backup mit folgendem Befehl ausgeführt werden:

ssh user@rpi "sudo /bin/tar -cpO --exclude=/proc --exclude=/tmp --exclude=/mnt --exclude=/dev --exclude=/sys / | xz" | > ~/pi/`date --rfc-3339=date`-pi3.tar.xz

user ist wieder durch euren Benutzernamen auf dem Pi und rpi durch den hostnamen oder die IP³-Adresse eures RPis zu ersetzen. Das ganze dauert dann eine ganze Weile, aber man muss ja nicht davor sitzen und zuschauen. 😄

⚠️ Warnung ⚠️
Das ganze ist erst mal mit etwas Vorsicht zu genießen, da ich jetzt nicht unnötig das Backup eingespielt habe um die SD-Karte nicht zu verschleißen aber die Dateigröße des erstellten Archivs wirkt auf mich plausibel und auch ein erster Blick ins Archiv sieht gut aus.

ls -lh ~/pi/      
insgesamt 2,2G
-rw-r----- 1 martin martin 1,6G Feb 20 19:29 2018-02-20-pi3.img.xz
-rw-r----- 1 martin martin 602M Mai 10 15:56 2018-05-10-pi3.tar.xz

Somit habe ich nun das Image, dass ich am Anfang mit dd erstellt habe mit dem ich ein funktionstüchtiges System auf eine neue SD-Karte im Falle eines Austauschs schreiben kann und ein aktuelles Backup der Daten.

Der aus meiner Sicht größte Vorteil des Umstiegs von Unity auf Gnome besteht darin, dass sich Ubuntu nun wesentlich freier konfigurieren lässt. In den folgenden Schritten stelle ich Ihnen meine persönliche Konfiguration vor. Vermutlich haben Sie ganz andere Vorlieben — aber vielleicht ist ja der eine oder andere Baustein dabei, nach dem Sie auch schon gesucht haben. (Wenn Sie eigene Tipps, haben, dürfen Sie gerne einen kurzen Kommentar verfassen …)

Gnome Tweaks

Die Gnome-Philosophie ist es, seine Anwender nicht durch unnötige Optionen zu verwirren. Erfreulicherweise können viele nützliche Einstellungen aber ganz unkompliziert in den Gnome Tweaks (deutscher Programmname Optimierungen) vorgenommen werden. Die Installation erfolgt mit apt install gnome-tweaks. Dort können Sie unter anderem einen freien Skalierungsfaktor für alle Schriften einstellen, Modale Dialoge vom Hauptfenster lösen, Fensterbuttons links oder rechts anzeigen etc.

Gnome Shell Extensions

Damit Gnome-Erweiterungen im Webbrowser konfiguriert werden können, müssen Sie ein zusätzliches Paket installieren: apt install chrome-gnome-shell. Danach besuchen Sie die Seite https://extensions.gnome.org. Dort klicken Sie auf den Link Click here to install browser extension und erlauben Sie die Aktivierung dieser Browser-Erweiterung. Anschließend laden Sie die Seite neu.

Dock

Ubuntus Dock ist eine reduzierte Variante der beliebten Gnome-Erweiterung Dash to Dock. Das Original bietet mehr Konfigurationsmöglichkeiten, weswegen ich die Erweiterung zuerst im Webbrowser installiert und das entsprechende Ubuntu-Paket dann entfernt habe: apt remove gnome-shell-extensions-ubuntu-dock. (Ohne die De-Installation kämpfen zwei Dock-Erweiterungen gegeneinander. Das eigentlich deaktivierte Dock von Ubuntu taucht nach Updates sonst immer wieder auf.)

Neben diversen Optionen, die die optische Gestaltung des Docks betreffen (z.B. dass das Dock nicht größer als 90% der Bildschirmhöhe werden soll), finden sich in den Konfigurationdialogen auch ausgesprochen nützliche Funktionen: Beispielsweise bewirkt die Einstellung Wirkung bei Mausklick = Minimieren, dass die betroffenen Fenster ein- und wieder ausgeblendet werden.

Ubuntu-Icon anstelle von »Aktivitäten«

Der Button Aktivitäten ist optisch ein Fremdkörper im Gnome-Panel. Ein dezentes Icon reicht vollkommen aus. Die Erweiterung Activities Configurator bietet neben unzähligen anderen Optionen die Möglichkeit, hierfür eine Bitmap-Datei auszuwählen. Ich habe das Ubuntu-Logo verwendet (/usr/share/icons/Humanity/places/64).

Systemmonitor

Techniker der ich nun mal bin will ich wissen, was auf meinem Rechner vor sich geht. Meine diesbezüglichen Wünsche erfüllt die Erweiterung system-monitor. Bevor die Erweiterung im Webbrowser aktiviert werden kann, müssen allerdings diverse Pakete installiert werden:

apt install gir1.2-gtop-2.0 gir1.2-networkmanager-1.0 gir1.2-clutter-1.0

Touchpad deaktiveren, sobald eine Maus angeschlossen ist

Das Touchpad meines Notebooks in Ehren, aber sobald ich eine Maus angeschlossen habe, ist mir die lieber. Und dann soll das Touchpad automatisch deaktiviert werden, um unbeabsichtigte Mausbewegungen und -klicks zu verhindern. Genau das kann die Erweiterung Touchpad Indicator. Damit die Erweiterung wunschgemäß funktioniert, müssen Sie im Konfigurationsdialog der Erweiterung im erste Dialogblatt die Umschaltmethode Xinput auswählen und im zweiten Dialogblatt die Option Touchpad automatisch ein- bzw. ausschalten aktivieren.

Alt+Tab wiederherstellen

Gnome kennt viel zu viele Tastenkürzel, um zwischen Fenstern und Programmen zu wechseln. Mir reicht eine, und die soll funktionieren, wie es einst unter Windows der Fall war. Diesen Wunsch erfüllt die simple Erweiterung Alternate Tab.

CapsLock deaktivieren

Die überflüssigste Taste jeder Tastatur ist CapsLock. Immer wieder führt ein unbeabsichtigtes Drücken zur eINGABE FEHLERHAFTEN tEXTS. Abhilfe: Im Programm Optimierungen (also Gnome Tweaks) gibt es im Dialogblatt Tastatur und Maus den merkwürdig beschrifteten Button Zusätzliche Belegungsoptionen. Er führt in einen Dialog, in dem Sie die Funktionen diverse Spezialtasten (Strg, Alt, Windows, CapsLock) verändern können. Dort gibt es auch die Möglichkeit, CapsLock ganz zu deaktivieren.

Nachtmodus

Gnome kann die Monitorfarben in der Nacht mit weniger Blau- und mehr Gelb- und Orange-Tönen darstellen. Das schont die Augen, ist aber natürlich zur farbechten Bearbeitung von Fotos ungeeignet. Die Option findet sich unter den gewöhnlichen Einstellungen (Dialogblatt Geräte / Anezigegeräte).

Ich habe heute morgen noch schnell den Beitrag Kommentare mit Github überabeitet. Als erstes hatte sich ein kleiner Fehler eingeschlichen, man muss natürlich die JS Datei nicht im Header einbinden sondern direkt im Beitrag, was ich auch bereits getan habe.

Zusätzlich habe ich das Script ein wenig angepasst, damit die CSP noch restriktiver sein können. So ergeben sich jetzt folgenden Regeln:

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

Das wichtigste war die erste Regel, direkten JS Code in der HTML Datei gilt als unsicher, und wird unteranderem vom Observatory Test von Mozilla mit 25 Punkten (bei 100 Punkten Gesamt) Abzug geahndet. Jetzt erhalten wir also auch wieder unser A+.

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.

Einige kleine und auch große Blogs haben es schon getan. Nun verlässt auch intux.de die eilitären Lesezirkel der Planeten von ubuntuusers.de und debianforum.de sowie den des OSBN. Der Hauptgrund hierfür sind die in letzter Zeit zunehmenden Troll-Kommentare.

intux.de wird es zwar in der bisherigen Form weiter geben, jedoch werden keine Artikel mehr auf anderen Seiten parallel veröffentlicht.

Ein großer Dank an all diejenigen, die gern die Beiträge auf intux.de gelesen haben.

Der Beitrag intux.de sagt bye bye erschien zuerst auf .

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

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

Bild von 3dman_eu via pixabay / Lizenz: CC0 Creative Commons

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!

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

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

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/