Neben der AusweisApp2 habe ich mit PyMOL eine weitere Anwendung für den Snap-Store paketiert.

Was ist PyMOL?

PyMOL ist ein 3D-Viewer und Editor für Proteine und im Bereich der Protoemik eine Standardanwendung. Nahezu alle Bilder, welche die Struktur von Proteinen zeigen, wurden mit Hilfe von PyMOL erstellt. Ein Beispiel sieht man hier:

Ein Problem der Software ist, dass sie in zwei Versionen vertrieben wird:

Eine kommerzielle Version mit Support und eine freie Version (MIT-Lizenz). Letztere enthält etwas weniger Features (z.B. kein Antialiasing in der OpenGL-Darstellung), für die meisten Benutzer ist diese aber vollkommen ausreichend. Die freie Version dürfte von den meisten Benutzern verwendet werden, da die günstigste Lizenz der kommerziellen Version $99 pro Jahr kostet.

Die kommerzielle Version wird mit einer kompletten Python-3.7-Umgebung ausgeliefert (Conda), die freie Version ist in vielen Distributionen verfügbar. Leider liefern gerade die LTS-Distributionen nur die Version 1.8 oder noch ältere Versionen aus. Als Anwender hat man also nur die Möglichkeit die kommerzielle Version einzusetzen oder das Programm aus dem Quellcode selbst zu bauen.

PyMOL selbst ist eine Mischung aus Python -und C++-Code. Die Oberfläche ist dabei in Python (PyQT, früher Tcl/Tk) realisiert, der grundlegende Code in C++. Die Anzahl der Abhängigkeiten ist zwar relativ klein, aber in dem Umfeld wo das Programm üblicherweise eingesetzt wird, finden sich nur sehr wenige versierte Linux-Benutzer, welche einfach so mal ein Programm kompilieren können. Vor allem, weil PyMOL ein externes Python-Modul und eine externe C++-Headerdatei benötigt, welche jeweils händisch installiert werden müssen.

Warum also ein Snap-Paket?

Ich habe das Paket eigentlich nur für knapp ein Dutzend Studenten an meiner Hochschule erstellt. Diese entsprechen dem oben genannten Umfeld und die Installation aus dem Quellcode ist für sie (noch) keine Option. Das Paket habe ich in den Store hochgeladen (Ich hätte auch die Snap-Datei direkt weitergeben können. Der Store ist also nicht unbedingt notwendig!), weil ich auch anderen Personen da draußen das Paket zur Verfügung stellen wollte (Wie richtig ich damit lag, kann man weiter unten lesen).

Durch den einfachen Aufbau der Snapcraft-YAML-Dateien konnte ich das Paket innerhalb weniger Stunden erstellen. Das externe Python-Modul lies sich z.B. mit wenigen Zeilen einbinden und direkt aus den Github-Quellen bauen:

pmw:
    plugin: python
    python-version: python3
    source-type: git
    source: https://github.com/schrodinger/pmw-patched.git
    stage-packages:
      - libpython3-dev
      - python3
    override-build:
      python3 setup.py --no-user-cfg install

Ich musste mir dadurch keine weiteren Gedanken darüber machen, wie ich das Modul einbinden kann. Bei einem Debian-Paket wären einige Verrenkungen notwendig geworden um dieses externe Modul und die Header-Datei einzubinden.

Der Hauptgrund warum ich ein Snap-Paket erstellt habe, war und ist die Tatsache dass ein solches Paket problemlos auf allen möglichen Distributionen eingesetzt werden kann. Als Entwickler oder Paket-Maintainer kann man sich komplett auf eine Laufzeitumgebung konzentrieren und kann sicherstellen, dass das Programm perfekt in dieser Umgebung funktioniert. Möglichen Problemen mit unterschiedlichen Versionen von Bibliotheken in den unterschiedlichen Distributionen wird dadurch komplett aus dem Weg gegangen.

Das größte Problem beim Erstellen von Snap-Paketen war mal wieder die Anpassung der Pfad. Ich musste z.B. das Shell-Skript zum Starten von PyMOL dahingehend anpassen, dass es erstens im korrekten Pfad nach dem Programm sucht und zweitens die Python3-Installation des Snap-Pakets benutzt.

Darum ein Snap-Paket!

Das ich mit der Erstellung des Pakets einen Nerv getroffen habe, habe einen Tag nach der Einstellung des Pakets in den Store erfahren. Ich habe keine 24 Stunden danach eine E-Mail eines Benutzers erhalten, welcher sich für die Erstellung des Pakets bedankt hat, weil er an der Kompilierung fast verzweifelt ist:

Dear Stefan,

Thanks so much for packaging pymol-oss as a snap!

I discovered this after a frustrating afternoon of failed cloning and compiling on Ubuntu 18.04.

The snap seems to work very well and it’s great to have the most recent version. I work on a large structural biology campus and will be communicating this to my colleagues. I imagine this will gain a lot of traction.

Best regards,

Darren

In der Welt der Penetrationstest Distributionen hat sich in den letzten Wochen wieder etwas getan. Zeit einen kurzen Blick darauf zu werfen.

Parrot 4.6 goes KDE

Bereits Ende April wurde Parrot 4.6 veröffentlicht. Die Distributionen ist nun als KDE Edition verfügbar (Mate wird ebenfalls weiter unterstützt).
Die Home und die Security Edition unterstützen beide Oberflächen.

Neben KDE hat sich das Design Team daran gemacht den Desktop und die Animationen frischer zu gestalten.

Technisch wurde HTTPS für den Paketmanager APT integriert. Ein Fallback auf HTTP ist den Mirror Servern vorbehalten.
Ein neuer Kernel darf ebenfalls nicht fehlen, dieser wurde auf Version 4.19 angehoben.

Viele Freunde hat das Paketformat Snap bisher noch nicht gefunden, dennoch wird es in Parrot nun im Anwendungsmenü angezeigt.

Auf der Softwareseite wurde mit Revolt ein Riot.IM Wrapper aufgenommen, dabei handelt es sich um einen Matrix Chatclient.

Reverse Engineering war die letzten Wochen durch das Release von Ghidra in aller Munde, das Parrot Team hat sich zunächst dagegen entschieden und Cutter, eine GUI für das radare2 Reverse Engineering Framework integriert.

Dazu kamen die üblichen Updates der vorhandenen Tools, auf die ich hier nicht weiter eingehen möchte

Kali 2019.2 goes Android

Kali NetHunter, die Android Variante der Sicherheitsdistributionen hat einen großen Schritt nach vorne gemacht. Hier werden nun bis zu 50 Android Varianten unterstützt.

•     Nexus 6 running Pie
•     Nexus 6P, Oreo
•     OnePlus2, Pie
•     Galaxy Tab S4 LTE & WiFi, Oreo

 
Die Desktop Version hat einen neuen Kernel 4.19.28 erhalten, dazu wurden einige Bugs gefixt und Tools wie seclists, msfpc, und exe2hex aktualisiert.

BlackArch 2019.06.01 goes new ISO

BlackArch Linux hat mit dem neuen Release nicht nur ein neues Installationsmedium erhalten, sondern wurde auch um 150 neue Tools erweitert. Eine Übersicht ist hier zu finden.

Der Kernel wurde auf 5.1.4 angehoben, sowie der Installer.

Übersicht 05/2019

Etwas verzögert habe auch ich mich getraut, Versionswechsel von 16.04 auf 18.04 und damit auch von Unity zu Gnome. Damit gehen 5 Jahre des Oberflächen-Experimentes zu Ende welches Ubuntu sich gewagt hat. Zurück bleibt das Gefühl das Unity eine durchaus gelungene Oberfläche mit durchaus Potenzial ist.

Einige Rechner haben leider nicht genug Rechenleistung für das neue System. Das 6 Jahre alte Notebook mit integrierter Grafik reicht nicht aus und auch der 15 Jahre alter P4 genügt trotz EMT64 Technik nicht.
Auch der Server in ViftualBox belasse ich nach einem Updatetest bei der “alten” Version. Aber den neuen Desktop wie auch Notebook habe ich frisch installiert.

Die Hardwareerkennung arbeitete tadellos und auch UEFI bereitete keine Probleme. Nach ungefähr 10 Minuten ist alles installiert. Selbst WLan und Drucker bereiten keine Probleme mehr.
Hier gibt es keinen Grund für Kritik.

Die Bedienung unterscheidet sich deutlich von Unity aber macht viel Spass und fühlt sich sehr modern an. Die Einstellungen haben sich vom Design her (z.b. Schieberegler) geändert und erinnern jetzt an ein Smartphone. Die Oberfläche reagiert sehr flüssig und kann auch mit exotischen Situationen flott umgehen. So ist es kinderleicht eine ssh und ftp Freigabe einzubinden und Dateien dort zu kopieren. Die mitinstallierten Programme sind aktuell und decken die alltäglichen Aufgaben ab.

Als Fazit kann ich festhalten das ich mit 16.04 sehr zufrieden war aber es auch Spass macht eine neue Oberfläche zu erkunden bei der alles so funktioniert wie es soll und man es erwartet. Interessant sind auch die Minimalinstallation sowie der neue Serverinstaller die einen fortschrittlichen Eindruck machen.

Ubuntu 18.04 ist ein Versuch wert.

Mittels Datei userContent.css respektive userChrome.css können Firefox-Nutzer beliebige CSS-Anpassungen an Webseiten sowie der Firefox-Oberfläche vornehmen. Ab Firefox 69 ist hierbei eine Änderung zu beachten.

Wird im Profilverzeichnis von Firefox ein Unterverzeichnis mit der Bezeichnung „chrome“ und darin eine Datei „userContent.css“ abgelegt, sind darüber alle denkbaren CSS-Anpassungen für jede beliebige Webseite umsetzbar – ganz ohne Erweiterung. Nach dem gleichen Prinzip können über die Datei „userChrome.css“ beliebige Design-Anpassungen an der Firefox-Oberfläche vorgenommen werden.

Es handelt sich dabei um ein sehr mächtiges Werkzeug von Firefox, welches Firefox bereits seit vielen Jahren besitzt und nur den Wenigsten bekannt ist.

Um die Startgeschwindigkeit von Firefox weiter zu optimieren – dies ist ein Performance-Schwerpunkt von Firefox 67 und nachfolgenden Versionen -, muss ab Firefox 69 ein Schalter in about:config aktiviert werden, damit diese beiden Dateien weiterhin eingelesen werden. Denn das Überprüfen auf die Existenz zweier Dateien dauert länger als das Überprüfen einer Firefox-Option und am Ende zahlen ausnahmslos alle Nutzer den Performance-Preis, obwohl von diesem mächtigen Feature kaum ein Nutzer Gebrauch macht.

Was muss ich tun?

Nutzer, die bereits eine userContent.css- und/oder userChrome.css-Datei haben

Bereits Firefox 68 setzt vollkommen automatisch eine interne Option, wenn eine Datei userContent.css oder userChrome.css gefunden wird. Sobald Firefox 69 erscheint, funktionieren daher beide Dateien wie gewohnt weiter. Der Nutzer muss überhaupt nichts weiter tun.

Nutzer, die noch keine userContent.css- und/oder userChrome.css-Datei haben

Wer bislang noch keine Datei userContent.css oder userChrome.css nutzt, dies aber ab Firefox 69 oder später tun möchte, muss über about:config zusätzlich den Schalter toolkit.legacyUserProfileCustomizations.stylesheets auf true setzen.

Fazit

Es existieren derzeit ausdrücklich keine Pläne, die Unterstützung für userContent.css oder userChrome.css aus Firefox zu entfernen. Bei dieser Änderung handelt es sich um eine reine Performance-Optimierung. Nutzer, welche eine Datei userContent.css oder userChrome.css anlegen, dürften mit dem Umschalten eines Schalters in about:config kein Problem haben. Gleichzeitig profitiert die ganz große Mehrheit der Firefox-Nutzer von einer verbesserten Startgeschwindigkeit.

Firefox 69 erscheint nach aktueller Planung am 3. September 2019.

Der Beitrag Firefox 69: Änderung für Nutzer von userContent.css und userChrome.css erschien zuerst auf soeren-hentzschel.at.

Das openSUSE-Projekt hat die nächste Minor-Version seiner stabilen Variante Leap veröffentlicht. In das System fließen die Änderungen im SP1 von SUSE Linux Enterprise 15 ein, sowie teilweise neue Paketversionen der Community. Insgesamt dient die Version allerdings der Systempflege und überrascht nicht mit aufregenden und fehlerträchtigen Änderungen.

Leap und Tumbleweed sind die komplementären Veröffentlichungen von openSUSE (siehe: openSUSE Leap). Während Tumbleweed als Rolling-Release Distribution konzipiert ist und die fortlaufenden Entwicklungen in der Linux-Communty widerspiegelt, ist Leap auf Stabilität ausgerichtet. Jede Hauptversion von Leap wird ca. 3 Jahre mit Updates versorgt. Die aktuell veröffentlichte Minorversion mindestens 18 Monate lang. Das System von Haupt- und Minorversionen kennt man von anderen Enterprise-Distributionen wie RHEL/CentOS (siehe: RedHat Enterprise Linux / CentOS)

Große Veränderungen erfolgen immer nur mit den Hauptversionen, während die Minorversionen lediglich der Produktpflege dienen und selektive Updates einspielen. Es sind daher keine systemumstürzenden Änderungen für diese Version zu erwarten.

Versionen

Basisversionen

OpenSUSE Leap übernimmt, wie auch die Vorgängerversion, einen großen Kernbestand an Paketen von SUSE Linux Enterprise 15. Hier integriert man nun die SP1 der Enterprise-Variante. Die neue Version basiert daher auf dem bereits recht abgehangenen Kernel 4.12. Hier nutzt man die gleiche Version wie in Leap 15.0. Hinzu kommt allerdings das neue Mesa 18.3.

Desktop

Im Desktopbereich bleibt man ebenfalls bei KDE Plasma 5.12, was aber der aktuelle LTS-Desktop des KDE Projekts ist. Bei GNOME bleibt man mit Version 3.26 ebenfalls bei der vorherigen Version. Einzug hält hingegen MATE 1.20. Nichts neues gibt es bei Xfce und LXDE, beide Projekte sind jedoch auch Upstream fast tot. OpenSUSE Leap folgt also dem bewährten Prinzip aktuelle Desktopversionen mit einer LTS-Basis zu verknüpfen.

Programme

Das Paket wird komplettiert durch KDE Applications. Im Gegensatz zu Plasma liefert man hier die leidlich aktuellen Version 18.12. Für Office liegt LibreOffice 6 vor, allerdings werden Updates hier erfahrungsgemäß an den Anwender weiter gereicht. Hinzu kommen natürlich viele weitere Programme. Die Paketquellen sind nicht so umfangreich wie bei Debian und Ubuntu, aber es gammeln durch den Releaseprozes von openSUSE auch deutlich weniger ungepflegte Programmleichen in diesem herum.

Neuerungen

Die Versionen deuten bereits an, dass es mit openSUSE Leap 15.1 keine Überraschungen gibt. Von zaghaften Versionsaktualisierungen abgesehen gibt es lediglich kosmetische Neuerungen.

Installationsroutine

Die Installationsroutine zeigt nun auf der linken Seite, wo man sich im Prozess befindet. Das ist ziemlich praktisch.

In der Installationsroutine hat man auch andere Änderungen aus SLE übernommen. Bei der Desktopauswahl im Abschnitt Systemrolle ist KDE Plasma nicht mehr vorausgewählt, sondern es gibt keine offensichtliche Präferenz. Der Anwender hat die Wahl zwischen KDE Plasma, GNOME, einem Allgemeinen Desktop, sowie den zwei Server-Varianten "Server" und "Transaktionaler Server". Plasma wird allerdings zuerst gelistet, wodurch die alte Präferenz noch ein wenig durchkommt.

Neu ist ebenfalls, dass der Anwender wählen darf ob er die leistungsmindernden Patches gegen die vielen Fehler in Intel-CPUs der vergangenen Monaten aktivieren möchte. Im in den Installationseinstellungen verbirgt sich das im Abschnitt Sicherheit unter dem etwas kryptischen Namen "CPU-Herabsetzung".

YaST

YaST hat ein neues Icon-Set spendiert bekommen, dass sich an Breeze anlehnt.

Programmauswahl

Frühere Versionen von openSUSE zeichneten sich durch eine teils widersprüchliche Standard-Programmauswahl aus. Teilweise auch unabsichtlich durch zirkuläre Abhängigkeiten der Pakete. Hier hat man deutlich aufgeräumt! OpenSUSE liefert zwar noch immer einen umfangreichen Desktop aus, aber z. B. digiKam und GIMP sind nicht mehr im Standardumfang. Im Unterschied zu Debian oder Ubuntu kann man hier aber in der Installationsroutine bereits eine individuelle Auswahl treffen.

Fazit

OpenSUSE Leap läuft sehr stabil, tendiert aber zunehmend dazu Neuerungen im Linux-Umfeld erst nach einiger Zeit zu integrieren. Leap bietet weiterhin einen konventionellen Linux-Desktop ohne ideologischen Überhang wie bei den puristischen KDE oder GNOME-Implementierungen, die z. B. KaOS oder Fedora ausliefern. Wer aktuellere Versionen benötigt muss allerdings zum Tumbleweed-Zweig greifen.

Trotz der abgehangenen Basis liefert man einen funktionalen Desktop ohne Überraschungen für den Anwender. Viele werden genau dies an openSUSE Leap schätzen.

OpenSUSE Leap hat bei mir sowohl als Server, wie auch für Desktopsysteme und virtuellem Maschinen einen festen Platz - Leap 15.1 wird daran nichts ändern, aber die Neuerungen sind so gering, dass es auch nicht sofort im Mai oder Juni auf alle Geräte muss. 

Bilder:
Einleitungs- und Beitragsbild von stevepb via pixabay

openSUSE Leap 15.1 ist ein reines Versions-Update ohne wesentlichen Neuerungen im Vergleich zu openSUSE 15.0. Und selbst bei den Versionsnummern hat sich wenig getan …

Installation

Das Installationsprogramm kann nur dann eine automatische Partitionierung der Festplatte/SSD vornehmen, wenn diese zumindest 12 GiB groß ist. In kleinen virtuellen Maschinen müssen Sie die Partitionen daher selbst einrichten.

Originell ist eine neue Sicherheits-Option CPU-Herabsetzung (eine abenteuerliche Übersetzung des englischen Begriffs CPU Mitigation): Damit können Sie steuern, ob die vielen Kernel-Bugfixes für Intel-CPU-Fehler aktiviert werden sollen (Standardeinstellung Auto) und ob darüberhinaus auch noch das Hyperthreading deaktiviert werden soll (Auto + SMT). Wenn Ihnen allfällige Sicherheitsprobleme gleichgültig sind und Sie mehr Wert auf eine hohe Geschwindigkeit legen, können Sie die Kernel-Bugfixes auch deaktivieren. Das Installationsprogramm baut dann den Kernel-Parameter mitigations=off in die GRUB-Konfiguration ein.

Versionsnummern

Wer gern mit aktuellen Software-Versionen arbeitet, ist bei openSUSE Leap fehl am Platz. (Tumbleweed ist diesbezüglich eine spannendere Alternative.)

Basis             Desktop             Programmierung   Server
---------------   ------------------  --------------   --------------
Kernel     4.12   KDE          5.12   bash       4.4   Apache     2.4
glibc      2.26   Firefox        60   gcc        7.4   CUPS       2.2
X-Server   1.20   Gimp          2.8   Java        11   MariaDB   10.2
Wayland    1.16   LibreOffice   6.1   PHP        7.2   OpenSSH    7.9
Mesa       18.3   Thunderbird    60   Python     3.6   qemu/KVM   3.1
Systemd     234                                        Postfix    3.3
NetworkMan 1.10                                        Samba      4.9
GRUB       2.02 

Bemerkenswert ist, dass beim Login eine Plasma-Session mit Wayland zur Auswahl steht. Standardmäßig kommt aber weiterhin Xorg zum Einsatz. Ich habe Wayland+KDE nur in einer virtuellen Maschine getestet. Dabei sind fallweise Darstellungsfehler aufgetreten. Ganz rund läuft es also noch nicht.

Links

• Download
• Release Notes openSUSE 15.1
• distrowatch

Mozilla hat Firefox 67 veröffentlicht. Auch Firefox 67 beinhaltet wieder zahlreiche Neuerungen. Dieser Artikel fasst die wichtigsten Neuerungen zusammen.

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

Firefox ist jetzt noch schneller

WebRender für erste Nutzer

WebRender stammt wie die mit Firefox 57 eingeführte CSS-Engine Stylo ebenfalls aus Mozillas Next-Generation-Engine Servo und ist in der Programmiersprache Rust geschrieben. Es handelt sich bei WebRender um einen Renderer für Webseiten-Inhalte, welcher unter stärkerer Einbeziehung der Grafikkarte als bisher im Grunde wie eine Spiele-Engine arbeitet, aber für das Rendering von Web-Content optimiert ist und dadurch große Performance-Vorteile liefern soll.

In Firefox 67 schafft es WebRender erstmals in eine finale Version von Firefox. Die Ausrollung erfolgt allerdings schrittweise über die nächsten Wochen. Außerdem erhalten WebRender in Firefox 67 ausschließlich Nutzer, welche Windows 10 als Betriebssystem sowie eine halbwegs moderne Grafikkarte von Nvidia einsetzen. Mit den nächsten Firefox-Updates und weiteren Verbesserungen der WebRender-Architektur wird WebRender dann für weitere Konfigurationen aktiviert werden.

Depriorisierung wenig genutzter Funktionen

Firefox 67 beschleunigt das Laden von Webseiten, indem beispielsweise die Timeout-Funktion verzögert wird. Auf Instagram, Amazon oder der Google-Suche soll diese Maßnahme für eine 40 bis 80 Prozent schnellere Ausführung des Haupt-Scripts sorgen. Alternative Stylesheets werden jetzt erst nach dem Laden der Webseite geladen und das Modul zum Ausfüllen von Formularen lädt Firefox ab sofort erst dann, wenn es auch ein Formular zum Ausfüllen gibt.

Entladen von Tabs, wenn der Speicher knapp wird

Sobald Firefox bemerkt, dass der verfügbare RAM des Computers auf unter 400 MB sinkt, werden Tabs, welche länger nicht mehr verwendet worden sind, entladen und geben damit Speicher frei. Sobald der Nutzer einen entladenen Tab wieder aktiviert, wird der Tab neu geladen. Dies ist nicht nur gut für die Performance bei Speicher-Knappheit, auch die Wahrscheinlichkeit von Out-of-Memory-Abstürzen wird damit reduziert.

Schnellerer Start von Firefox

Auch die Performance des Programm-Starts von Firefox war eine Priorität in Firefox 67 und wird auch in weiteren Updates ein wichtiger Schwerpunkt mit weiteren Verbesserungen bleiben. Vor allem Nutzer mit Add-ons sollten in Firefox 67 von einer verbesserten Startgeschwindigkeit profitieren, da unwichtige Prozesse beim Start nun übersprungen werden.

Schneller JavaScript-Compiler für ARM64

Auch auf Windows-Geräten mit ARM64-Architektur besitzt Firefox nun einen performanten JavaScript-Compiler.

Weiter Verbesserungen der Privatsphäre

Cryptomining- und Fingerprinting-Blocker

Mozilla hat seinen integrierten Content-Blocker um die Möglichkeit erweitert, Cryptomining– sowie Fingerprinting-Scripts zu blockieren. In Firefox 67 sind die beiden neuen Blocker-Kategorien standardmäßig noch deaktiviert und können in den Datenschutz-Einstellungen von Firefox aktiviert werden. In späteren Versionen von Firefox werden diese Kategorien standardmäßig aktiviert sein.

Nutzer entscheiden, welche Erweiterungen in privaten Fenstern aktiv sind

Ab Firefox 67 werden private Fenster noch ein Stück privater, denn ab dann sind Erweiterungen in privaten Fenstern standardmäßig nicht länger aktiviert und können so nicht länger Aktivitäten ausführen, welche in Widerspruch mit dem Konzept privater Fenster stehen. Firefox weist nach dem Update beim ersten Start eines privaten Fensters in Form eines Dialogs darauf hin.

Dies betrifft jedoch lediglich neu installierte Erweiterungen. Damit sich Nutzer nicht über plötzlich nicht mehr funktionierende Erweiterungen wundern, erhalten alle bereits installierten Erweiterungen automatisch die Berechtigung, auch in privaten Fenstern aktiv zu sein. Für bestehende Nutzer ändert sich also erst einmal nichts, bis die nächste Erweiterung installiert wird. In der Detail-Ansicht des Add-on Managers kann für jedes Add-on individuell eingestellt werden, ob dieses in privaten Fenstern aktiv sein soll oder nicht.

Im Add-on Manager markiert Firefox sämtliche Erweiterungen, welche die Berechtigung erhalten haben, auch in privaten Fenstern aktiv zu sein. Oberhalb der Erweiterungen steht eine Erklärung mit Link auf eine Hilfe-Seite von Mozilla.

Mehr Sicherheit für Firefox-Nutzer

Geschlossene Sicherheitslücken

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

Benachrichtigungen nur noch über HTTPS

Die verschlüsselte Übertragung von Daten im Web gewinnt immer mehr an Bedeutung. Bereits über 78 Prozent aller von Firefox-Nutzern geladenen Webseiten werden über HTTPS anstelle von HTTP übertragen.

Längst sind bestimmte Features nur noch in einem sogenannten gesicherten Kontext nutzbar. Von einem sicheren Kontext spricht man bei der Verwendung von HTTPS, aber auch verschlüsselte WebSocket-Verbindungen (wss://) sowie lokale Ressourcen (wie http://localhost/ oder file://) werden als sicherer Kontext betrachtet.

Ab Firefox 67 erfordern auch sogenannte Web-Benachrichtigungen einen sicheren Kontext. Außerdem hat Mozilla Vorkehrungen gegen Benachrichtigungs-Spam getroffen.

Benachrichtigungen möchte Mozilla in naher Zukunft übrigens auch weniger nervend für den Nutzer machen.

FIDO-Unterstützung für verbesserte Web-Kompatibilität

Firefox 60 war 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 hat. Die FIDO U2F API kann als so etwas wie ein Vorgänger dieser API gesehen werden und wird leider immer noch von teilweise großen Diensten genutzt.

Darum unterstützt Firefox 67 nun einen Teil der FIDO U2F API, damit auch Firefox-Nutzer unter anderem bei Google die Zwei-Faktor-Authentifizierung nutzen können.

Dedizierte Profile pro Installation

Lesezeichen, Chronik, Erweiterungen, Passwörter, Einstellungen – diese und noch weitere Dinge werden in einem sogenannten Profil gespeichert. Verschiedene Firefox-Installationen nutzen bisher standardmäßig immer das gleiche Profil.

Ab Firefox 67 nutzt der Mozilla-Browser dedizierte Profile pro Installation. Das heißt, dass wenn ein Nutzer mehrere Firefox-Installation hat, jede dieser Installationen ein eigenes Profil verwendet und damit standardmäßig nicht länger in allen Installationen automatisch die gleichen Lesezeichen, die gleiche Chronik etc. zur Verfügung stehen. Wer seine Daten profilübergreifend synchron halten möchte, nutzt dafür idealerweise Firefox Sync, was genau für diesen Zweck ausgelegt ist.

Die Vorteile dieser Änderung, wie beispielsweise der parallele Betrieb von Firefox und Firefox Beta, werden in einem gesonderten Artikel behandelt.

Verbesserungen des Passwort-Managers

Mozilla hat in Firefox 67 gleich mehrere Verbesserungen des integrierten Passwort-Managers vorgenommen.

Die auffälligste Neuerung ist, dass Benutzernamen- und Passwortfelder, welche von Firefox vervollständigt worden sind, nun farblich hinterlegt werden. Das ist konsistent zur Vervollständigung von Formularfeldern, einer anderen Funktion von Firefox. Auch dabei werden von Firefox vervollständigte Felder in dieser Farbe hinterlegt.

Ist für eine Webseite nur ein Passwort gespeichert, füllt Firefox dieses bei Besuch bisher standardmäßig automatisch aus. In den Firefox-Einstellungen wurde nun eine sichtbare Option implementiert, um dieses Verhalten abzuschalten.

Eine weitere Neuerung betrifft private Fenster. In diesen erlaubt es Firefox bisher nicht, Passwörter zu speichern. Ab Firefox 67 kann Firefox auch in privaten Fenstern Passwörter von Webseiten speichern. Der Unterschied zu regulären Fenstern ist, dass der Speichern-Dialog in privaten Fenstern nicht automatisch aufploppt, sondern der Nutzer dafür zunächst das Schlüsselsymbol in der Adressleiste anklicken muss. Wem das nicht gefällt, der kann diese Neuerung über about:config deaktivieren, indem der Schalter signon.privateBrowsingCapture.enabled auf false gesetzt wird.

Außerdem wurde in das Hauptmenü ein Menüpunkt hinzugefügt, um schneller auf die gespeicherten Zugangsdaten zugreifen zu können, ebenso wurde unterhalb der vorgeschlagenen Logins für ein Passwort-Feld ein Link zu den Passwörtern ergänzt. In Passwort-Feldern mit autocomplete=“new-password“ werden nicht länger Passwörter vorgeschlagen.

Neuer Synchronisations-Button

Beim Start von Firefox 67 fällt in der Navigations-Symbolleiste von Firefox eine neue Schaltfläche auf. Wer noch nicht Lesezeichen, Chronik und Zugangsdaten synchronisieren lässt, wird hierüber auf das Synchronisations-Feature von Firefox aufmerksam gemacht und gelangt direkt zur Anmeldung.

Wird bereits Firefox Sync genutzt, dann erscheint anstelle des allgemeinen Icons das Avatar des Nutzers als Schaltfläche. Darüber stehen dem Nutzer verschiedene Funktionen in Zusammenhang mit Firefox Sync zur Verfügung.

Konkret kann der Nutzer hierüber Tabs an ander Geräte senden, Tabs von anderen Geräten öffnen, die Sidebar mit den Tabs von anderen Geräten anzeigen, ein weiteres Gerät mit Firefox Sync verbinden, die Einstellungen des Firefox Accounts öffnen, die Synchronisations-Einstellungen von Firefox öffnen sowie die Synchronisation der Daten manuell anstoßen.

Wer die neue Schaltfläche nicht braucht, kann diese natürlich wie jede andere Schaltfläche auch von der Firefox-Oberfläche entfernen, entweder über Menü > Anpassen oder per Rechtsklick auf die Schaltfläche und Auswahl des entsprechenden Menü-Eintrags.

Anheften von Tabs wird prominenter

Per Rechtsklick auf einen Tab und „Tab anheften“ kann ein Tab in Firefox angeheftet werden, das heißt, dass der Tab am linken Rand der Tableiste positioniert wird, platzsparend nur mit Favicon und ohne Seitentitel angezeigt wird sowie vor versehentlichem Schließen geschützt ist. Außerdem werden angeheftete Tabs nach dem Start von Firefox umgehend geladen und müssen, anders als reguläre Tabs, nicht erst angeklickt werden, ehe sie aktiviert werden. Praktisch ist dieses Feature vor allem für Tabs, die man permanent geöffnet haben möchte, beispielsweise das E-Mail-Postfach, einen Kalender oder ein soziales Netzwerk.

Dadurch, dass diese Funktion bisher nur durch einen Rechtklick auf einen Tab erreicht werden kann, ist dieses Feature nicht unbedingt jedem Nutzer bekannt. Ab Firefox 67 befindet sich eine entsprechende Option auch in dem Menü, welches bei Klick auf das Symbol mit den drei Punkten in der Adressleiste erscheint.

Und wem das noch nicht weit genug geht, der kann per Rechtsklick auf diesen neuen Menüeintrag das Symbol direkt in der Adressleiste von Firefox platzieren und damit jederzeit Tabs mit nur einem einzigen Klick anheften und wieder lösen.

Außerdem kann Firefox jetzt von sich aus unter bestimmten Voraussetzungen auf das Feature zum Anpinnen von Tabs aufmerksam machen.

Screenshot-Upload entfernt

Firefox Screenshots ist ein seit Firefox 56 in Firefox integriertes Werkzeug zur Aufnahme von Bildschirmfotos, welches erlaubt, entweder nur den sichtbaren Bereich einer Webseite, die komplette Webseite oder einen beliebigen Ausschnitt abzubilden. Die Screenshots können entweder in die Zwischenablage kopiert oder auf dem Computer gespeichert werden. Außerdem war es bislang möglich, die Bilder online auf screenshots.firefox.com zu speichern.

In Firefox 67 hat Mozilla die Möglichkeit entfernt, die Bilder in die Mozilla-Cloud hochzuladen. Mit dem Wegfall der Upload-Möglichkeit fällt auch die Schaltfläche weg, die eigenen Screenshots aufzurufen, sowie die Bildbearbeitungsmöglichkeiten, da diese nur für die online gehosteten Bilder zur Verfügung standen. Über die Gründe der Abschaltung kann hier mehr erfahren werden.

Nutzer, welche die Upload-Funktion in der Vergangenheit genutzt haben, können ihre Bilder exportieren, ehe in den nächsten Monaten der Server abgeschaltet wird.

Mozilla experimentiert mit geänderter Startseite (nur Englisch)

Manche Nutzer einer englischsprachigen Version sehen eine veränderte Standard-Startseite von Firefox, da Mozilla hier mit verschiedenen geänderten Layouts experimentiert, um mehr Pocket-Inhalte anbieten zu können. Am Experiment teilnehmende Nutzer können über die Startseiten-Einstellungen von Firefox aussteigen.

Verbesserungen für Firefox-Erweiterungen (WebExtensions)

Eine Übersicht über Neuerungen für Erweiterungs-Entwickler gibt es hier.

Verbesserungen der Webplattform

Schnellerer AV1-Decoder und auch für Linux

Seit Firefox 65 unterstützt der Mozilla-Browser den neuen Video-Codec AV1, damals allerdings nur für Nutzer einer 64-Bit-Version von Windows. Mit Firefox 66 kam die Unterstützung für die 32-Bit-Version von Windows sowie Apple macOS dazu. Und mit Firefox 67 unterstützt nun auch Firefox für Linux den AV1-Codec.

Außerdem hat Mozilla den AV1-Decoder durch dav1d vom VideoLAN-Projekt ersetzt. Dieser ist deutlich performanter als die bisher verwendete Referenz-Implementierung.

Die technische Überlegenheit von AV1 gegenüber H.264 lässt sich ganz gut in Zahlen ausdrücken, indem man sagt, dass mit AV1 die gleiche Qualität bei etwa der halben Dateigröße wie bei H.264 erreicht werden kann. Das heißt also: Schnellere Ladezeiten für Nutzer bei entsprechender Nutzung durch die Webseiten.

Dazu kommt, dass AV1 frei von jeglichen Patenten ist. Nach Angaben von Mozilla kommt in 80 Prozent aller Videos, die wir uns im Web ansehen, patentierte Technologie zum Einsatz, was deutlich macht, wie wichtig AV1 ist. Denn was vielen nicht klar ist: die Wiedergabe von Videos kostet Geld. Selbst wenn wir für die Wiedergabe von Videos nichts zahlen: sobald patentierte Technologie zum Einsatz kommt, muss jemand bezahlen. Jedes Jahr werden von vielen Firmen viele Millionen nur dafür bezahlt, dass wir kostenlos Videos in hoher Qualität konsumieren können.

Sonstige Verbesserungen der Webplattform

Mit dem prefers-color-scheme Media Query können Webseiten nun das Design in Abhängigkeit davon anpassen, ob der Nutzer seitens Betriebssystem angegeben hat, ein helles oder ein dunkles Design zu bevorzugen. Dieser Media Query wird neben Firefox auch von Safari unterstützt, Chrome soll später im Jahr folgen.

Es wurde das CSS-Schlüsselwort revert hinzugefügt, um eine Eigenschaft auf ihren Originalwert zu setzen.

Firefox unterstützt jetzt dynamische JavaScript Modul-Imports und die JavaScript-Methode String.prototype.matchAll().

Dies war nur eine kleine Auswahl an Änderungen der Webplattform. Weitere Informationen zu Verbesserungen der Webplattform in Firefox 67 finden sich in den MDN web docs.

Neuerungen für Webentwickler

Der Inspektor von Firefox beinhaltet ein Panel, welches Änderungen zeigt, die am CSS der Seite vorgenommen worden sind. Hier wurde nun eine Kopieren-Funktion ergänzt.

In der Netzwerkanalye kann die Größe der Spalten jetzt verändert werden.

Der JavaScript-Debugger hat diverse Verbesserungen erhalten, welche hier vorgestellt werden.

Der Canvas Debugger, der Web Audio Editor sowie der Shader Editor wurden aus Firefox entfernt. Für alle drei Tools gibt es Alternativen in Form von Erweiterungen.

Weitere Informationen zu Verbesserungen für Webentwickler in Firefox 67 finden sich in den MDN web docs.

Enterprise Features

Firefox 67 unterstützt eine neue Policy zum Aktivieren oder Deaktivieren der Netzwerk-Anmeldeseite, eine neue Policy zum Aktivieren oder Deaktivieren von DNS-Prefetching, eine neue Policy zum Aktivieren oder Deaktivieren automatischer Erweiterungs-Updates sowie eine neue Policy zum Hinzufügen eines Support-Eintrags im Hilfe-Menü. Auch storage.managed lässt sich nun per Policy konfigurieren. Die Policy zum Hinzufügen von Suchmaschinen unterstützt jetzt außerdem auch POST als Anfragemethode.

Tipp: Mit dem Enterprise Policy Generator wird die Konfiguration von Firefox zum Kinderspiel. Die aktuelle Version 4.4 ist bereits für Firefox 67 angepasst.

Meine Code-Beiträge zu Firefox 67

Auch ich habe wieder Code zu Firefox 67 beigetragen. Neben einer Darstellungs-Anpassung bei Anzeige der Release Notes einer Erweiterung im Add-on Manager habe ich den Import von Daten aus anderen Browsern prominenter gemacht. Dieser kann nun über das Datei-Menü gestartet werden. Der Menüeintrag berücksichtigt auch die entsprechende Enterprise Policy und erscheint deaktiviert, wenn der Datenimport durch den Administrator abgeschaltet worden ist.

Sonstige Neuerungen in Firefox 67

Mozilla hat die Zugänglichkeit der Oberfläche mit der Tastatur verbessert. So können jetzt auch die Schaltflächen in der Symbolleiste, in der Adressleiste und das Menü mit der Tastatur erreicht werden.

Beim Markieren von mehreren Tabs sind die markierten Tabs jetzt wesentlich besser sichtbar.

Firefox 67 ist außerdem Voraussetzung für Device Pairing – das Verbinden eines anderen Gerätes mit Firefox Sync über einen QR-Code, wie es unter anderem in Mozillas neuem Android-Browser Fenix möglich sein wird.

Nächste Version: Firefox 67.0.1

Bereits am 4. Juni geht es weiter: Dann nämlich erscheint mit Firefox 67.0.1 eine Sonder-Veröffentlichung, mit welcher Mozilla die Privatsphäre standardmäßig noch weiter verbessern wird.

Der Beitrag Mozilla veröffentlicht Firefox 67 mit WebRender und Cryptomining-Blocker erschien zuerst auf soeren-hentzschel.at.

Der schwelende Streit zwischen den USA und Huawei gipfelte nun vorläufig im Ausschluss Huaweis vom Betriebssystem Android, das bisher die Smartphones des Herstellers antrieb. Die Episode illustriert wie wenig Android mit Freiheit und den Prinzipien von freier Entwicklung gemein hat.

Google beendet die Geschäftsbeziehungen zu Huawei auf Druck der US-Regierung, die Huawei verdächtigen mit seinen Produkten Spionage zu betreiben. Konkret bedeutet dies, dass Huawei künftig keinen Zugriff mehr auf die Google Apps inklusive es Play Stores hat. Sicherheitsupdates erhält man ebenfalls nicht mehr direkt von Google. Huawei könnte lediglich über das Android Open Source Projekt (AOSP) weiterhin auf die Quellen zugreifen. Der weitere Verlauf ist unklar, erinnert an wenig an das Embargo gegen ZTE, allerdings unterscheiden sich die Vorwürfe.

Die App-Einschränkungen gelten nach aktuellen Erkenntnissen nicht für bereits verkaufte Geräte, was die zahlreichen Kunden beruhigen dürfte. Unklar ist aber ob Huawei noch zeitnah Sicherheitsupdates liefern kann. Huawei lag im ersten Quartal 2019 schließlich vor Apple auf Platz 2 der Anbieter mit den größten Absatzzahlen.

Das "Rumpf-Android", wie Heise es nennt, dürfte weder für Huawei, noch für die Kunden sonderlich attraktiv sein. Zu dem Schluss bin ich ganz persönlich ja erst gestern gekommen (siehe: Android ohne Google Play - Featurephone mit Touchscreen). Natürlich könnte Huawei versuchen eine eigene App-Infrastruktur einzuführen, aber das dürfte außerhalb Chinas scheitern. Schon Amazon musste das einsehen.

Die aktuellen Ereignisse zeigen mal wieder, dass Android nichts, wirklich gar nichts, mit den Idealen freier Software zu tun hat. Es ist ein System, das federführend von Google entwickelt wird und das in unregelmäßigen Abständen der Öffentlichkeit in Form von AOSP vor die Füße geworfen wird. Alle Bestandteile, die das System für Endverbraucher attraktiv machen, hat Google in proprietäre Bestandteile ausgelagert. Das betrifft scheinbar sogar die monatlichen Sicherheits-Bulletins. Ohne Kooperation mit Google kann kein Anbieter Android wirklich sinnvoll einsetzen.

Freie Software und transparente Entwicklung sehen anders aus. Google hat sich - wie so oft - geschickt das positive Image von Open Source Software zu Eigen gemacht, ohne Einblick in die Entwicklung zu geben oder der Community Mitsprache einzuräumen. Das erinnert ein wenig an Oracle nach der Sun-Übernahme. Nur genießt Oracle in der Community interessanterweise nicht den guten Ruf von Google.

Android ist nicht die Rettung von Linux in der mobilen Welt, sondern beschädigt den Ruf des Pinguin.

Bilder:
Einleitungs- und Beitragsbild von annemazo via pixabay

Seit zwei Jahren nutze ich wieder ein iPhone (siehe: Tschüß BlackBerry - Hallo iPhone), genauer gesagt ein iPhone SE. Von dieser Modellreihe ist kein Nachfolger in Sicht und daher nahm ich kürzlich wieder Android ins Blickfeld. Dort gibt es schließlich sehr vielfältige Hardware zu attraktiven Preisen.

Android Smartphones kann man leider nicht direkt wie gekauft verwenden. Im besten Fall hat der Hersteller das System nur mit zahlreichen zusätzlichen Apps versehen - im Windows-Jargon Bloatware - im schlimmsten Fall gibt es eine veraltete Android-Version und keine Sicherheitsupdates. Alle auf dem deutschen Markt erhältlichen Modelle haben zudem das Google-Paket vorinstalliert.

Das ist hinsichtlich des Datenschutzes absolut indiskutabel. Zum Play Store kommen auch in den minimalen Varianten Play Services hinzu. Diese aktualisieren sich am System vorbei und entziehen sich der Kontrolle des Anwenders. Angesichts der Art und Weise wie Google Geld verdient - nämlich mit zielgerichteter Werbung auf Basis gesammelter Daten - kann man das Prinzip Datenschutz dann gleich ad acta legen.

Möglich ist natürlich eine Custom Rom wie LineageOS und freie Apps von F-Droid zu installieren. Ich bin kein Smartphone-Junkie, sondern benutze das Gerät zur Organisation, sowie zur schriftlichen und verbalen Kommunikation. Also eigentlich ziemlich klassisch. Benötigt werden abseits der Basisfunktionen wie Browser, Kamera & Co:

• Kalender und Aufgaben
• Notizen
• Office-Paket mit zumindest rudimentären Bearbeitungsfunktionen
• Karten / Navigation
• DB Navigator
• Messenger (WhatsApp, Signal, Threema, SMS)
• E-Mail

Einiges davon ist bereits per Standard enthalten, anderes wie Karten lässt sich mit OsmAnd gut realisieren oder hat bekannt gute Apps wie K-9 Mail. Einige andere Bereiche sind aber schwierig umzusetzen. Jetzt kann man sich über einzelne Wünsche sicherlich streiten. Voraussichtlich dürfte vor allem der DB Navigator, WhatsApp und Threema auf Kritik stoßen. Alle drei sind für mich persönlich allerdings unverzichtbar.

Ich fahre sehr viel mit der Deutschen Bahn, der DB Navigator ermöglicht es mir Tickets zu kaufen und kontrollieren zu lassen ohne Ausdrucke. Das spart Papier und ist teilweise sogar unverzichtbar weil viele Provinz-Bahnhöfe im deutschen Nordwesten gar keine Automaten der DB mehr haben, sondern nur noch welche der Nordwestbahn und anderer Konkurrenten. Natürlich nehme ich billigend in Kauf, dass die DB mein Fahrverhalten trackt, aber dank BahnCard und BahnBonus tut sie das potenziell sowieso. Letzteres beschert mir aber in derart schöner Regelmäßigkeit Freifahren, dass ich das Datenschutz-Risiko in Kauf nehme. Zumal die entsprechenden DSGVO-Abfragen eine überschaubare Datensammlung ergeben haben.

Messenger sind ein ebenso schwieriges Thema. Natürlich fände ich es wünschenswert wenn alle meine Kontakte Signal (das im übrigen auch nicht via F-Droid zur Verfügung steht) verwenden würden. Alle mein Signal-Kontakte fallen aber in die Kategorie "Nerd". Threema nutzen hingegen ca. 1/3 meiner Kontakte und WhatsApp 95%. Ich missioniere nicht und habe auch keine Lust aus allen Gruppen-Kommunikationen ausgeschlossen zu sein und immer nur Zusammenfassungen via SMS zu erhalten. Threema und WhatsApp kann man auch per Direktdownload nutzen. Signal drängt einen geradezu in den Play Store, bietet aber auch einen Download. Man hat durch die ganzen Direkt-Downloads aber ein erhebliches Sicherheitsrisiko und den Komfort von Windows XP.

Leider sind das nicht die einzigen Problemzonen. Im Office-Bereich gibt es nur eine Alpha-Version des Viewers von LibreOffice und sonst nichts.

Dabei handelt es sich außerdem nur um die notwendigen Basisfunktionen. Komfortlösungen wie mobiles bezahlen oder Drittanbieter-Dienste lassen sich quasi gar nichtu umsetzen.

Das sind schon schwere Einschränkungen. Streng genommen ist Android mit F-Droid auf dem Niveau meines BlackBerry Bold 9900 mit OS 7.1 von 2011. Wenn mich meine Erinnerung nicht trügt hatte ein altes Symbian-Nokia auch schon in etwa die Funktionalität. Was damals als Smartphone-Vorreiter durchging ist heute ein besseres Featurephone. Natürlich bietet Android sehr viele Freiheiten, weil es Open Source ist und einen nicht wie Apple in einen Käfig steckt, aber was nützt mir das, wenn es funktional nichts bietet. Letztlich befindet man sich in einem Open Source Universum, das durch seine beschränkten Angebote einem Gefängnis nicht unähnlich ist.

Die Recherche hat leider mal wieder ergeben, dass ich mein iPhone SE hoffentlich noch lange behalten darf und anschließend vermutlich wieder ein neues iPhone kaufe.

Bilder:

Einleitungs- und Beitragsbild von Pexels via pixabay

Vor einigen Jahren habe ich eine Übersicht verfügbarer LTS Distributionen zusammen gestellt. Einen Artikel zu dem Thema gab es damals auch noch in freiesmagazin 07/2015. Seitdem pflege ich die Übersicht (siehe: Linux - Eine sichere Basis) und hatte immer vor dort noch eine sechste Distribution zu veröffentlichen. Doch die scheint es nicht zu geben.

LTS Distributionen bzw. Enterprise Distributionen sind für viele Privatanwender wichtig. Linux-Enthusiasten und Versions-Junkies können sich das nicht vorstellen, aber viele Anwender haben kein Interesse an Neuerungen. Die einmal eingerichtete Version soll am besten die komplette Lebensdauer der Hardware abdecken. Für sie ist der Linux-Desktop bereits funktional perfekt. Ein Umstand, der eigentlich für Linux spricht. Nervige Fehler sollen per Updates bereinigt werden und keine Versionsaktualisierungen nach sich ziehen.

Eine schwierige Frage ist die nach der Abgrenzung zwischen einer normalen Distribution mit Release-Zyklen und einer LTS-Distribution. Während Rolling Release-Distributionen bereits durch ihr Entwicklungsmodell leicht heraus zu filtern sind, haben herkömmliche Distributionen auch definierte Supportzeiträume. Der einzige greifbare Unterschied ist der Supportzeitraum. Hier markiert Debian praktisch die Grenze. Debian Stable ist in der Community zweifelsohne als Enterprise-tauglich bzw. LTS-Distribution akzeptiert. Die Supportzeiträume sind aber nicht besonders lang. Zwischen zwei Versionen liegen meist nur 2 Jahre, wobei ein Übergangszeit von 12 Monaten gewährleistet ist. Die insgesamt 3 Jahre Unterstützung von Debian markieren daher die Untergrenze für eine LTS Distribution, die 10 Jahre von Red Hat und SUSE Linux Enterprise das Maximum.

Bisher berücksichtigt sind:

• Debian GNU/Linux
• Ubuntu LTS
• SUSE Linux Enterprise Desktop
• openSUSE Leap
• RedHat Enterprise Linux / CentOS

Geplant war immer noch Scientific Linux, aber diese Distribution wird nun eingestellt. Linux Mint, elementaryOS, KDEneon etc. sind nicht bersücksichtigt, da sie sich ihren LTS-Status lediglich von Ubuntu leihen und die Desktopumgebungen trotz stabiler Basis volatil weiterentwickelt werden.

Daher die Frage: Fehlt da noch etwas? Gibt es eine Distribution, die ich übersehen habe?

Bilder:
Einleitungs- und Beitragsbild von rawpixel via pixabay

Mit einer der wichtigsten Anwendungen meines Heimservers neben Mailserver und Photogallerie ist das Streamen von Musik. Jeden Abend wird es von mir genutzt und versorgt mein Smartphone mit Liedern.

Als Software auf dem Server (Ubuntu Server 16.04) setzte ich MiniDLNA ein. Es ist in den Paketquellen enthalten und schnell mit einem “apt install minidlna” installiert. Auch der Konfigurationsaufwand hält sich in Grenzen. Eine handvoll Einstellunge kann man in der /etc/minidlna.conf verändern, hauptsächlich den Port, das Verzeichnis mit den Medien sowie den Namen der übermittelt wird.
Man kann auch mit den Standarteinstellungen arbeiten und legt die Musik einfahc in “/var/lib/minidlna” ab.

Als Client nutze ich diverse Geräte. Mein Festplattenrekorder kann die Musik davon ebenso abspielen wie das IP Telefon und selbstverständich auch das Smartphone.
Besonders in den Appstores der Smartphones gibt es eine reichliche Auswahl so das für jeden Geschmack das passende dabei ist.

Als Dateiformat setzte ich bevorzugt auf OGG wenn ich eine Musik-CD von mir dort verfügbar mache. Aber bei gekaufter Musik kommt auch MP3 zum Einsatz. Hier muss ich anmerken das der Festplatenrekorder mit den OGG Dateien nichts anfangen kann.

CentOS 8 ist noch nicht verfügbar. Deswegen habe ich mir eine 30-tägige Testversion von Red Hat Enterprise Linux 8 (RHEL 8) besorgt, um mir ein erstes Bild vom neuen Linux-Server-Standard zu machen.

Installation

Wer schon einmal Fedora oder CentOS installiert hat, stößt bei RHEL 8 auf wenig Überraschungen. Der Partitionierungsdialog ist unübersichtlich wie eh und je, davon abgesehen ist die Installation aber ein Kinderspiel.

Registrierung

Der Code von RHEL ist zwar Open Source, die Nutzung der Enterprise-Distribution und insbesondere der Zugriff auf die Paketquellen erfordert aber eine Lizenz. Die Aktivierung der 30-Tage-Testlizenz hat sich mühsamer gestaltet als erwartet. Der grafische Red Hat Subscription Manager, offenbar eine Art Web-Console, hat bei meinen Tests kläglich versagt. Wenn es dem Programm überhaupt gelang, eine Verbindung zu Red Hat herzustellen, dann scheiterte der Login mit der Fehlermeldung, die Organisation sei ungültig. In meinem für die 30-Tage-Evaluation eingerichteten Account bei https://access.redhat.com/management gibt es aber gar keine Möglichkeit, eine Organisation einzustellen.

Letztlich ist die Registrierung in einem Terminalfenster gelungen (und auch dort erst im fünften oder sechsten Versuch …):

subscription-manager register --username <yourname> --password <pw>
subscription-manager role          --set="Red Hat Enterprise Linux Server"
subscription-manager service-level --set="Self-Support"
subscription-manager usage         --set="Development/Test"
subscription-manager attach
  Aktueller Status der installierten Produkte:
  Produktname: Red Hat Enterprise Linux for x86_64
  Status:      Subskribiert

yum update
  Updating Subscription Management repositories.
  ....

Nach der erfolgreichen Registrierung zeigte dann auch der grafische Subscription Manager den korrekten Status an. Das ändert aber nichts daran, dass ich bei der Inbetriebnahme von RHEL 8 öfters an eine andere Firma gedacht habe (M…t).

Update 17.5.2019: Auf einem PC (also nicht in einer virtuellen Maschine) habe ich heute eine weitere RHEL-8-Installation durchgeführt. Deren Aktivierung im Rahmen eines Red Hat Developer Accounts gelang mit dem grafischen Subscription Manager auf Anhieb. Vielleicht hatte ich gestern einfach Pech?

Paketverwaltung und AppStreams

dnf/yum: Fedora ist schon vor Jahren auf dnf umgestiegen, RHEL jetzt auch (genaugenommen auf die dnf-Version 4.0). Aus Kompatibilitätsgründen kann das Kommando weiterhin mit yum aufgerufen werden. Auch in der Red-Hat-Dokumentation ist immer von yum die Rede.

Aus Sicht eines Fedora-Anwenders extrem lästig ist, dass bei yum install libre<tab> das Autocomplete funktioniert (wenn auch mit sekundenlangen Verzögerungen), mit dnf install libre<tab> hingegen nicht. Red Hat drängt seine Anwender also dazu, das Kommando als yum und nicht als dnf aufzurufen.

AppStream: Das in Fedora 28 eingeführte Modularity-Konzept wurde wie erwartet in RHEL integriert und hat bei der Gelegenheit auch gleich den neuen Namen AppStreams erhalten. Ein Blick in die Liste des AppStream-Repositories vermittelt den Eindruck, als würden sich ein Großteil aller Pakete nun dort befinden (und nicht mehr in der Basis-Paketquelle). Hier finden Sie ausführliche Dokumentation zum AppStream-Konzept in RHEL.

AppStreams geben viel neuer Flexibilität, machen den Umgang mit Paketen aber nicht unbedingt einfacher. Das Gnome-Programm Software kommt mit AppStreams überhaupt nicht zurecht und findet die meisten Programme ganz einfach nicht. Immer wieder frage ich mich, was dieses Programm in einer Distribution zu suchen hat, die sich an Administratoren, Entwickler etc., also in der Regel an Profis richtet.

Module sind Gruppen zusammengehöriger Pakete. yum module list liefert eine Liste aller Module. Dabei tauchen bekannte Namen wie mariadb, mysql, nginx, nodejs, php, python36 etc. auf. yum module info <name> liefert Details zu einem Modul:

yum module info mariadb

Name             : mariadb
Stream           : 10.3 [d][a]
Version          : 820190206164045
Context          : 9edba152
Profiles         : client, server [d], galera
Default profiles : server
Repo             : rhel-8-for-x86_64-appstream-rpms
Summary          : MariaDB Module
Description      : MariaDB is a community developed branch of MySQL ...
Artifacts        : Judy-0:1.0.5-18.module+el8+2765+cfa4f87b.x86_64
                 : galera-0:25.3.23-5.module+el8+2765+cfa4f87b.x86_64
                 : mariadb-3:10.3.11-1.module+el8+2765+cfa4f87b.x86_64
                 : mariadb-backup-3:10.3.11-1.module+el8+2765+cfa4f87b.x86_64
                 : mariadb-common-3:10.3.11-1.module+el8+2765+cfa4f87b.x86_64
                 : mariadb-devel-3:10.3.11-1.module+el8+2765+cfa4f87b.x86_64
                 : mariadb-embedded-3:10.3.11-1.module+el8+2765+cfa4f87b.x86_64
...

Um alle Pakete aus einem Modul zu installieren, führen Sie yum module install <modulname> aus.

Es ist nicht immer leicht zu erkennen, ob es von einem Modul mehrere Versionen gibt. (Das entscheidende Feature von AppStream ist es ja, dass ein Paket bzw. ein ganzes Modul in verschiedenen Versionen zur Verfügung gestellt werden kann. Das bedeutet aber nicht, dass alle Pakete im AppStream-Repository von dieser Funktion Gebrauch machen. Vielmehr gibt es von der Mehrheit der Pakete aktuell nur eine Versionsnummer.)

yum module info <name> zeigt immer nur die Hauptversion (Defaultversion) an. Ob es mehrere Versionen gibt, können Sie mit yum module list --all bzw. yum module list --all <name> ermitteln. Das trifft aktuell nur für die Module container-tools, perl und postgresql zu.

yum module list --all postgresql

Name          Stream      Profiles            Summary                                                              
postgresql    10 [d]      client, server [d]  PostgreSQL server and client module                                  
postgresql    9.6         client, server [d]  PostgreSQL server and client module          

Bei postgresql gilt also 10 als Default-Version. Wenn Sie davon abweichend die ältere Version 9.6 installieren möchten, führen Sie dieses Kommando aus:

yum module install postgresql:9.6
yum install @postgresql:9.6             (Kurzschreibweise)

Tipp: Wenn Sie ein Paket partout nicht finden, hilft zumeist yum search <name> weiter.

EPEL: Wie üblich beschränkt sich Red Hat bei den Paketen auf das Wesentliche. Wer nicht-offizielle Pakete sucht, wurde in der Vergangenheit in der EPEL-Paketquelle fündig. Allerdings unterstützt EPEL momentan RHEL 8 noch nicht. Es gibt Berichte, wonach die EPEL-Quellen für RHEL 7 auch für RHEL 8 funktionieren, aber eine optimale Lösung ist das natürlich nicht.

Flatpak: Die Flatpak-Bibliotheken sind standardmäßig installiert. Die Defaultausstattung für eine Desktop-Installation umfasst aber keine Flatpak-Pakete, und Software ist nicht in der Lage, nach Flatpaks zu suchen. Flatpaks befinden sich also gewissermaßen im »Stealth-Modus«, gut verborgen vor einer irrtümlichen Anwendung ;-)

Versionsnummern

Die folgende Tabelle fasst die wichtigsten Versionsnummern in RHEL8 zusammen.

Basis             Desktop             Programmierung   Server
---------------   ------------------  --------------   --------------
Kernel     4.18   Gnome        3.28   bash       4.4   Apache     2.4
glibc      2.28   Firefox ESR    60   gcc        8.2   CUPS       2.2
X-Server   1.20   Gimp          2.8   Java      8/11   MariaDB   10.3
Wayland    1.15   LibreOffice   6.0   PHP        7.2   MySQL      8.0
Mesa       18.3   Thunderbird    60   Python 2.7/3.6   OpenSSH    7.8
systemd     239                                        qemu/KVM  2.12
NetworkMan 1.14                                        Postfix    3.3
GRUB       2.02                                        Samba      4.9

Natürlich ist RHEL nicht so aktuell wie Fedora. Aber Gimp 2.8?

Java-8-Pakete gibt es im Supplementary Repository.

LibreOffice, MariaDB, MySQL und Thunderbird sind im AppStream Repository versteckt.

Interessant ist mitunter auch, was fehlt: Nicht in den offiziellen Paketquellen enthalten sind unter anderem Docker und KDE. (Gnome ist der einzig offizielle Desktop für RHEL. Und zu Docker bietet Red Hat eigene Alternativen an.)

Zuletzt noch die Links zu den offiziellen Paketlisten: Basispakete und AppStream-Pakete

Desktop und Grafik

Für RHEL-7-Anwender macht Gnome mit Version 3.28 einen recht großen Sprung. Bemerkenswert ist auch, dass der Gnome-Classic-Modus zwar weiterhin angeboten wird; standardmäßig kommt jetzt aber das »richtige« Gnome mit der Gnome-Shell zum Einsatz. Wenn möglich, wird als Grafiksystem Wayland verwendet. Xorg steht natürlich weiter zur Verfügung.

Sonstige Neuerungen, veraltete Technologien

• Das Dateisystem btrfs wird explizit nicht mehr unterstützt, das Kernelmodul steht nicht mehr zur Verfügung. Standardmäßig kommt xfs zum Einsatz, alternativ steht ext4 zur Wahl.

• Firewalls basieren hinter den Kulissen auf der Nftables-Infrastruktur. Das Kommando iptables ist dazu kompatibel und funktioniert unverändert.

• Wie bereits erwähnt, erfordert der Einsatz von RHEL (wie bisher) nicht gerade billige Lizenzen. Es gibt aber eine Ausnahme: Ein Basis-Image für den Container-Einsatz steht kostenlos zur Verfügung (siehe z.B. diesen Artikel auf zdnet.com). Für Entwickler gibt es im Rahmen des Red Hat Developer Program eine kostenlose Lizenz (nicht für den produktiven Einsatz).

• Das Programm virt-manager zur Verwaltung von virtuellen Maschinen mit QEMU/KVM steht zwar weiter zur Verfügung, gilt aber als deprecated. Virtuelle Maschinen sollen nun in Cockpit eingerichtet werden. Das erfordert die Installation von cockpit-machines. Update 18.5.2019: Mittlerweile habe ich mir cockpit-machines angesehen. Da wird noch etwas Zeit vergehen, bis der virt-manager wirklich in den Ruhestand gehen kann. Die Verwaltung virtueller Maschinen im Cockpit versagt schon bei den Grundfunktionen.

• Das Paket network-scripts gilt ebenfalls als deprecated. Für die Netzwerkkonfiguration ist nun alleine der NetworkManager zuständig. (Ich muss wohl meine Empfehlung revidieren, den NetworkManager bei Server-Installationen sofort zu entfernen. Das fällt mir schwer, zu oft habe ich dieses Programm schon verflucht …) Die Kommandos ifup und ifdown stehen weiterhin zur Verfügung, rufen aber den NetworkManager (nmcli) auf.

Cockpit

Beim ersten ssh-Login schlägt RHEL vor, ich solle doch das vorinstallierte Cockpit mit systemctl enable --now cockpit.socket aktivieren. Da lasse ich mich doch nicht zweimal bitten ….

Cockpit ist eine Webkonsole, die einen Systemüberblick gibt und grundlegende administrative Funktionen erfüllt. Der Funktionsumfang wächst, wenn Zusatzpakete wie cockpit-machines, cockpit-composer etc. installiert werden. Die Bedienung erfolgt über den Webbrowser (Adresse localhost:9090). Beim Login gelten die normalen Linux-Accounts. Ein root-Login ist möglich, und auch »gewöhnlichen« Benutzer können mittels sudo bzw. mit PolicyKit (pkexec) administrative Aufgaben erledigen.

Etwas konsterniert war ich, als ich bemerkt habe, dass Port 9090 nicht durch eine Firewall blockiert wird und nach außen hin zugänglich ist. Zudem fehlt Cockpit jeder Schutz gegen automatisierte Passwort-Cracker. Auch wenn sich die Cockpit-Entwickler eine Menge Gedanken gemacht haben, wie sicher Cockpit ist, erscheint mir das Setup doch mutig. Wenn Cockpit vorinstalliert ist, hätte man eigentlich fail2ban samt Cockpit-Regeln auch vorinstallieren können. (Hätte man nicht, weil fail2ban in den Paketquellen fehlt. Voraussichtlich wird das Paket in der EPEL-Paketquelle zu finden sein. Außerdem scheint es in fail2ban aktuell keine fertigen Regeln für Cockpit zu geben. Immerhin protokolliert Cockpit gescheiterte Login-Versuche, siehe journalctl -u cockpit.)

Ich will den Teufel jetzt nicht an die Wand malen, aber ich kann mir wirklich nicht vorstellen, dass ein gedankenloses Aktivieren von Cockpit sicherheitstechnisch empfehlenswert ist. Ob es eine gute Idee ist, dass Red Hat quasi bei erster Gelegenheit eine Anleitung zur Inbetriebnahme von Cockpit präsentiert, muss sich erst weisen.

CentOS 8

CentOS 8 ist in Arbeit, aber es ist nicht abzusehen, wie lange es dauern wird, bis die neue Version fertiggestellt wird. Einen groben Überblick über den Status der Arbeiten finden Sie auf der CentOS-Projektseite.

Quellen/Links

• RHEL8-Ankündigung im Red-Hat-Blog
• Download (RHEL8 kann zwar kostenlos heruntergeladen werden, vor dem Einrichten der Paketquellen müssen Sie die Installation aber registrieren.)
• 30-Tage-Testversion
• Release Notes
• Considerations in Adopting RHEL 8
• Überblick RHEL-Dokumentation
• AppStreams
• Red Hat Base Images (Red Hat Blog)
• Red Hat Base Images (Artikel auf zdnet.com)

Red Hat Developer

Im Rahmen des Developer Programs stellt Red Hat eine kostenlose Lizenz für Entwicklungsarbeiten (nicht für den produktiven Einsatz) zur Verfügung:

• Red Hat Developer
• Red Hat Developer FAQ
• RHEL 8 Cheatsheet

Cockpit

• Cockpit
• Cockpit auf GitHub
• Is Cockpit secure?
• Cockpit in den RHEL Release Notes
• Getting started with Cockpit (bezieht sich auf RHEL7, ein entsprechendes RHEL8-Dokument habe ich nicht gefunden)
• Neuerungen in Cockpit
• Vorstellung von Cockpit (golem.de, 2015)

Tests / Berichte

• Test bei heise.de
• Bericht bei golem.de
• Distrowatch

Vor einigen Tagen habe ich auf meinem Computer weiter auf LVM umgestellt und vor allem an den Homeverzeichnissen geschraubt. Bisher waren diese über eine ausgesprochen unschöne Variante auf /mnt/hddX/home/... gesymlinkt. Diese temporäre Lösung hatte mehrere unschöne Nebeneffekte wie z.B. doppelte Dateien in einigen IDEs, welche die Pfade absolut aufgelöst in ihren Configs speicherten.

Bei der Migration in die neuen LVM Logical Volumes (LV), auf denen sich die Dateisystem betreiben lassen, wollte ich dann größere Verzeichnisse ebenfalls auslagern, darunter einige Standardverzeichnisse wie Videos und Downloads. Macht man dies allerdings im laufenden Betrieb, kann sich offenbar der GNOME-Dateimanager Nautilus 3.32 daran stören: dieser "vergisst" einfach mal die Standardverzeichnisse.

Um diese nun wiederherzustellen, müssen wir in die Datei gehen, die die Standardverzeichnisse unter GNOME koordiniert: die $HOME/.config/user-dirs.dirs. In dieser Datei werden für bestimmte (selbsterklärende) Variablen die jeweiligen Verzeichnisse (optimalerweise homedir-relative, d.h. mit $HOME statt ausgeschriebenem Username) definiert. An dieser Stelle können auch Änderungen der Verzeichnisnamen getroffen werden, wenn z.B. Desktop dem vor einigen Jahren eingeführten Defaultnamen Schreibtisch vorgezogen werden soll.

Was war bei mir nun konkret in der Datei passiert? Die entsprechenden XDG-Variablen waren auf "$HOME/" gesetzt. Kein Wunder, dass die Einträge nicht mehr in den Favoriten angezeigt und in der Liste mit besonderen Icons hinterlegt wurden. Eine Änderung samt Neustart der Shell konnte das Problem beheben.

Ich habe eine neue Version des Snap-Pakets veröffentlicht. Dieses beinhaltet das Treiberpaket von „Reiner SCT“ für den PC/SC-lite Daemon.

Dadurch unterstützt der Daemon z.B. den „Reiner SCT cyberJack RFID standard. Dessen Treiber wurde im CCID-Treiber 1.4.30 auf Bitte von „Reiner SCT“ deaktiviert.

Das Update wird von „snap“ automatisch durchgeführt. Man kann es auch per „snap refresh ausweisapp2-ce“ anstoßen.

Die Entwickler-Werkzeuge von Firefox 68 erhalten eine neue Funktion, welche erklärt, wieso bestimmte CSS-Eigenschaften auf Webseiten nicht den gewünschten Effekt haben.

Ein Problem, welches vermutlich viele kennen, die Webseiten erstellen: Man hat einem Element eine Eigenschaft per CSS zugewiesen, wundert sich dann aber, wieso nicht das passiert, was passieren soll. Ab Firefox 68 kann der Mozilla-Browser in solchen Situationen helfen.

Dann nämlich stellt Firefox inaktives CSS im Regeln-Panel des Inspektors blass und mit einem Info-Symbol dar. Fährt man mit der Maus über das Symbol, erscheint eine Erklärung, wieso diese Regel inaktiv ist. Zum Beispiel würde bei der Verwendung der Eigenschaft align-items außerhalb eines Flex- oder Grid-Containers die Erklärung kommen, dass diese Eigenschaft nur mit display: flex oder display: grid einen Effekt hat.

Die Neuerung ist bislang noch auf Nightly-Versionen von Firefox beschränkt, kann ab Firefox 68 aber auch darüber hinaus aktiviert werden, indem über about:config der Schalter devtools.inspector.inactive.css.enabled auf true gesetzt wird. Bislang sind erst diverse Regeln für Flex- und Grid-Layouts implementiert, es sind aber bereits zahlreiche weitere Regeln in Planung, nach denen Firefox in Zukunft Hinweise geben kann.

Firefox 68 erscheint nach aktueller Planung am 9. Juli 2019.

Der Beitrag Firefox 68: Entwickler-Werkzeuge erklären, wieso CSS auf Webseiten nicht funktioniert erschien zuerst auf soeren-hentzschel.at.

sudo verhält sich unter Ubuntu in einem Detail anders als bei den restlichen Linux-Distributionen: Nach sudo -s verwendet root nicht sein eigenes Home-Verzeichnis (/root), sondern das des zuletzt aktiven Benutzers (/home/accountname). Das hat diverse Vor- und Nachteile — und führt offensichtlich zu Sicherheitsproblemen.

Der feine Unterschied

Fedora und die meisten anderen Linux-Distributionen verhalten sich so:

kofler@fedora$ echo $HOME
  /home/kofler

kofler@fedora$ sudo -s

root@fedora# echo $HOME
  /root

Unter Ubuntu gilt hingegen:

kofler@ubuntu$ echo $HOME
  /home/kofler

kofler@ubuntu$ sudo -s

root@ubuntu# echo $HOME
  /home/kofler

Vorteile

Das Verhalten von Ubuntu hat den Vorteil, dass nach sudo -s diverse Einstellungen (/home/accountname/.vim, /home/accountname/.emacs usw.) auch für root gelten. Das ist natürlich praktisch.

Die von anderen Linux-Distributionen abweichende sudo-Konfiguration wurde 2011 in einer Reaktion auf diesen Bugbericht eingeführt.

Nachteile

Mit sudo ausgeführte Programme erzeugen in /home/accountname Dateien mit root-Rechten, die der gewöhnliche Benutzer dann nicht mehr überschreiben kann. Das ist immer wieder lästig, aber nicht wirklich tragisch. (Abhilfe schaffen sudo rm xxx oder sudo chown xxx.)

Allerdings kann das Verhalten unter Umständen auch Sicherheitsprobleme verursachen, wie sie in diesem Bugbericht (erstellt im März 2016!) dokumentiert sind. Deswegen regt der Canonical-Mitarbeiter Dan Streetman nun sowohl im Bugbericht als auch in der Ubuntu-Developer-Mailingliste an, dass Ubuntu in zukünftigen Versionen zurück zur sudo-Defaultkonfiguration wechselt. (Eine Änderung in den aktuellen Versionen erscheint ein zu großer Eingriff.)

Selbsthilfe

Wenn Sie nicht auf die nächste Ubuntu-Version warten möchten, fügen Sie einfach die folgende Zeile in /etc/sudoers ein:

# /etc/sudoers
...
Defaults always_set_home

Quellen

• Bugbericht 1556302
• Bugbericht 1373495
• Bugbericht 760140
• Diskussion in der Ubuntu-Developer-Mailingliste

2016 erschien die erste Auflage meines Git-Buches, bei dem ich auch darüber schrieb, welche Open und Closed Source Software ich verwendet habe, um das Buch zu schreiben.

In diesem Artikel geht es um das gleiche Thema wie letztes Mal, mit dem Unterschied, dass ich über die Arbeit an der zweiten Auflage des Buches welches jetzt erschien. Nähere Informationen zu dem Buch finden sich hinter dem Link.

Allgemein geht es in diesem Artikel die Tools die ich selbst verwendet habe und nicht die, die beim Verlag eingesetzt wurde. Wie auch im letzten Mal habe ich versucht so viel Open-Source-Software wie möglich einzusetzen.

Das Schreiben

Bei der ersten Auflage schrieb ich den ersten Entwurf zunächst in Vim und überführte es dann nach LibreOffice Writer, wo die Dateien dann vom Verlag weiterverarbeitet wurden.

Für die zweite Auflage arbeitete ich direkt in LibreOffice weiter, wo ich die Änderungen eingepflegt habe. Um ein Diff zwischen den Versionen anschauen zu können, verwendete ich odt2txt, was ich in meine Git-Konfiguration eingebunden habe. Das funktioniert zwar nicht so gut wie bei reinen Text-Dateien, aber besser so, als gar kein Diff zu haben.

Beim Verlag bzw. beim Satz des Buches wurde FrameMaker verwendet. Berührungspunkte hatte ich allerdings damit keine.

Die Grafiken

Im Buch muss ich diverse Dinge visualisieren. Dazu gehören sowohl Darstellungen der Git-Historie, als auch Veranschaulichungen bei Workflows beim Arbeiten mit Remote-Repositorys.

In der ersten Auflage griff ich nach einigen Experimenten mit Tools wie Graphviz auf yEd Graph Editor. Hauptgrund für die Auswahl von yEd war, dass ich ohne größeren Anstrengungen und mit wenig Aufwand solche Grafiken erstellen konnte. Nachteil von yEd: es ist ein kein quelloffenes Tool und die enthaltenen Abbildungen empfand ich zum Teil als altbacken.

Als neues Tool setzte ich dieses Mal auf draw.io. Das funktioniert sowohl im Browser bzw. Web, als auch als Electron Anwendung auf dem Desktop. Ich griff dabei auf die Installation über das Flatpak-Paket zurück. Das Tool steht zwar unter der Apache 2.0 Lizenz, die Entwicklung geschieht allerdings größtenteils im Verborgenen. Das sieht man auch sehr stark, wenn man sich die Git-Historie auf dem master Branch anschaut: Bis auf wenige Ausnahmen enthält jeder einzelne Commit die Änderungen einer kompletten Version. Eine nachvollziehbare Historie ist dies hingegen nicht.

Eine Migration der mit yEd erstellen Grafiken war allerdings nicht möglich, sodass ich alle Grafiken neu erstellt habe.

Statistiken

Bei der ersten Auflage konnte ich noch eine kleine Statistik erstellen in dem ich die Anzahl und Uhrzeiten der Git-Commits ausgewertet habe. Dies ging bei der zweiten Auflage nicht ganz so gut, weil viel weniger Commits notwendig waren. Ich begann die Arbeit an der zweiten Auflage am Heiligabend 2018 und endete am 26. April 2019. Insgesamt wurden es 53 Commits. Effektiv gearbeitet habe ich in diesem Zeitraum natürlich nicht jeden Tag, da ich fast ausschließlich am Wochenenden, Urlaubstagen und in Zügen der Deutschen Bahn daran gearbeitet habe. Zum Vergleich: Für die Fertigstellung der ersten Auflage lagen zwischen dem ersten und dem letzten Commit 308 Tage und 287 Commits, also knapp über 10 Monate.

Und nun?

Mit Abschluss meines Masterabschlusses Anfang Dezember und Fertigstellung der zweiten Auflagen des Buches sind meine Großprojekte der letzten Jahre erstmal abgeschlossen. Mal schauen was ich mir jetzt ans Bein binde. ;)

Der SUSE Linux Enterprise Desktop (SLED) ist die Enterprise-Distribution der traditionsreichen Firma SUSE aus Nürnberg. Im Gegensatz zu RHEL gibt es aber keinen Community-Klon und somit auch keine kostenfreie Version. Die Distribution eignet sich deshalb primär für den professionellen Unternehmenseinsatz, kann aber auch von Privatkunden genutzt werden.

Die Version 15 von SLED erschien bereits vor circa einem Jahr als Teil der jüngsten Version der Enterprise-Familie von SUSE. Die angekündigte Supportdauer liegt bei 10 Jahren, weshalb der Anwender theoretisch bis 2028 lediglich Minor-Updates auf die kommenden Service Packs vollziehen muss. Das Produkt richtet sich vor allem an Unternehmenskunden, kann aber auch von Privatanwendern lizensiert werden. Ohne Supportpaket, d. h. lediglich mit den technischen Updates aber ohne Hilfe und Beratung, kostet das ganze 42€ pro Jahr oder 113€ für 3 Jahre. So mancher an die Kostenlos-Kultur gewöhnte Linux-Anwender mag da aufstöhnen, aber für diesen Preis bekommt man 10 Jahre Support für den Desktop und eine grundsolide Distribution. Wer es preiswerter mag kann sich den Community-Ableger openSUSE Leap ansehen, der sich mit SLED die Basis teilt (siehe: openSUSE Leap).

Installation

Bei Interesse an SLED kann man eine 60-Tage Testversion bei SUSE beziehen. Man erhält dann einen Registrierungscode mittels dessen man bei der Installation die Paketquellen freischalten kann. Ansonsten ähnelt die Installation weitgehend openSUSE, lediglich der dunkle Farbton erinnert daran, dass man SLED installiert. Als einziger Desktop steht GNOME zur Auswahl, bei dem man die Wayland oder X11 Variante nehmen kann. Was hier sinnvoll ist hängt ganz von der eigenen Hardware ab. Minimalisten können zudem noch auf IceWM zurückgreifen.

Das Betriebssystem schlägt bei der Partionierung Btrfs für die System-Partition und XFS für Home- bzw. Datenpartitionen vor. Hier geht SUSE einen Sonderweg, der aber bei openSUSE bereits seit Jahren gut funktioniert und vor allem durch automatische Snapshots überzeugt.

Modul-System

Im Unterschied zu openSUSE bindet SLED so genannte Module ein. Dies ermöglicht die selektive Aktualisierung von einzelnen Softwaregruppen und findet sich analog auch bei der jüngsten Veröffentlichung von RHEL. Über das Modulsystem ist auch der PackageHub von openSUSE verfügbar, über den die Community via OBS zahlreiche Pakete zur Verfügung stellt, die normalerweise nicht in SLED enthalten sind. Für diese gibt es dann zwar keinen Enterprise-Support, aber oftmals ist die Verwendung dieser Pakete auf dem Desktop ohne Alternative.

Basissystem

SLED verwendet einen stark modifizierten Kernel 4.12, was sich über die Produktlaufzeit auch nicht mehr ändern wird. Dieser ist im November 2017 erschienen und damit natürlich schon etwas älter, was aber bei Enterprise-Distributionen üblich ist. Dies ergänzen an der Basis GCC 7.4, Mesa 18.02, Cups 2.2.7 und systemd 234.

Die Systemverwaltung erfolgt wie üblich via YaST und en zugehörigen Modulen.

Desktop

Der einzige unterstützte Desktop ist die GNOME Shell und die zugehörigen Programme. Man verwendet hier die Version 3.26, die - ähnlich wie der Kernel - aus dem Herbst 2017 stammt. Ähnlich wie bei openSUSE hat man der GNOME-Umgebung ein einheitliches Design im SUSE-Stil verpasst, das subjektiv einigermaßen gelungen ist. Im Gegensatz zu früheren Versionen bzw. anderen Enterprise-Distributionen verzichtet man auf den Einsatz von Shell-Addons um der Shell ein klassisches Aussehen zu verpassen.

Programmauswahl

SUSE installiert bei einer Standardinstallation eine gute Komposition von Standardprogrammen. Neben LibreOffice in Version 6.1.5 und Firefox in der aktuellen ESR Version stammen die meisten Programme aus dem GNOME-Projekt. Brasero, Cheese, Evolution, Fotos etc. pp. Hinzu kommen andere Programme, die das GTK Toolkit nutzen wie z. B. GIMP, Pidgin & Co.

Die Verfügbarkeit von Flatpak in den Paketquellen erweitert zudem die Möglichkeit Desktop-Applicationen außerhalb der Paketquellen zu installieren.

Zusammengefasst

Wer braucht SUSE Linux Enterprise auf dem Desktop? Diese Frage stellt man sich immer wieder bei so einem Test. Neben Unternehmenskunden dürften das vor allem Anwender sein, die extrem lange Ruhe im System haben wollen und mit dem RHEL-Klon CentOS nichts anfangen können. Andere Distributionen mit 10 Jahren Support gibt es nämlich nicht. Alle anderen Anwender können auch zu openSUSE Leap greifen und müssen nach ca. 3 Jahren ein Distributions-Upgrade machen.

Ähnlich wie RHEL/CentOS muss man bei SLED mit GNOME zu Recht kommen, da alternative Desktopumgebungen nicht angeboten werden. Ein Umstand, der angesichts der erratischen KDE-Entwicklung aber nachvollziehbar ist.

Wer also in der SUSE-Welt heimisch ist und GNOME schätzt, bekommt für knapp 50€ im Jahr ein grundsolides System, das einen in Ruhe arbeiten lässt.

An unserer Schule verwenden wir  Citrix Hypervisor (ehemals XenServer) (bald xcp-ng) für die Virtualisierung unseres Schulservers und anderer Anwendungen. Citrix liefert mit XenCenter ein Verwaltungstool für Windows. Damit kann man bequem alle virtuellen Maschienen verwalten und Einstellungen am Citrix Hypervisor vornehmen. Eine andere Möglichkeit ist Xen Orchestra. Es ist ein webbasiertes Tool, was noch einiges mehr als XenCenter kann. Auf der Website kann man sich eine fertig eingerichtete Appliance herunterladen. Diese ist allerdings von den Features stark eingeschränkt (man hat ca. 2 Wochen Zeit alle Features zu testen). Deshalb möchte ich einen kleinen Tipp weitergeben, wie man Xen Orchestra installieren kann – mit allen Features der Enterprice und Premium Edition.

Xen Orchestra installieren

Xen Orchestra ist eine Open Source Projekt, deshalb kann es sich jeder selbst den Quellcode nehmen und installieren. Die Anleitung dazu findet man in der offiziellen Dokumentation. Auf Github findet man auch ein Installationsskript, welches die Installation automatisch durchführt. Damit kann man Xen Orchestra in wenigen Schritten installieren. Auf einem frischen Ubuntu LTS Server muss man nur die folgenden Befehle ausführen:

$ sudo bash
$ curl https://raw.githubusercontent.com/Jarli01/xenorchestra_installer/master/xo_install.sh | bash

Das war es auch schon 🙂 Xen Orchestra kann man nun unter IP des Servers erreichen. Der Standard-Benutzername ist admin@admin.net, das Password admin.

Xen Orchestra aktualisieren

Wenn man Xen Orchestra fertig eingerichtet hat und sollte man es natürlich aktuell halten, um alle Sicherheitsupdates und neue Features zu bekommen. Eigentlich bringt jede Version einige neue Features mit, welche die Arbeit mit dem XenServer (bzw. xcp-ng) erweitern oder erleichtern. Der Autor des Installationsskript stellt ein weiteres Skript für die Aktualisierungen bereit. Zu finden ist es ebenfalls auf Github.

Das Aktualisierungsskript bietet verschiedene Optionen an. Zum einfachen Aktualisieren reicht der folgende Aufruf:

$ sudo bash
$ sudo curl https://raw.githubusercontent.com/Jarli01/xenorchestra_updater/master/xo-update.sh | bash

Nach wenigen Minuten ist Xen Orchestra wieder auf den aktuellen Stand!

Wer sich unwohl dabei fühlt ein Skript aus dem Netz als root laufen zu lassen, kann sich das Skript natürlich vorher noch genau anschauen, was es macht bzw. nicht macht 🙂

Fazit

Xen Orchestra ist ein tolles Projekt. Unser XenServer lässt sich damit leicht verwalten. Backups sind schnell angelegt (seit neustem auch Backups der Konfiguration von Xen Orchestra) inklusiver Benachrichtigungen (eMail oder nach Slack / Mattermost). Diese beiden Skripts haben uns das Leben sehr erleichtert. Ein großes Dankeschön an Jarli01!

1 Kommentar

Der Beitrag Xen Orchestra installieren und aktualisieren (Vollversion) erschien zuerst auf .:zefanjas:..

Als weitere Folge des Erweiterungs-Problems vom Wochenende hat Mozilla die Veröffentlichung von Firefox 67 verschoben.

Aufgrund eines Zertifikat-Problems kam es am Wochenende zu einem Problem, welches zur Deaktivierung sämtlicher Erweiterungen für Nutzer von Firefox, Firefox ESR und Firefox für Android sorgte. Auch die Installation neuer Erweiterungen sowie Aktualisierung von Add-ons verweigerte Firefox.

Mozilla hatte in Form eines Hotfixes und zweier Updates für Firefox 66 reagiert. Und auch auf den kommenden Release hat dies Auswirkungen: So hat Mozilla nun die Veröffentlichung von Firefox 67, ursprünglich geplant für den 14. Mai, auf den 21. Mai verschoben.

Die zusätzliche Zeit wird benötigt, um die Qualität von Firefox 67 sicherzustellen, nachdem die Ereignisse der letzten Tage, so kurz vor der geplanten Veröffentlichung von Firefox 67, ein umfangreiches Testen der Release Candidates von Firefox 67 verhinderten und es zwei späte ungeplante Updates gab.

Auf die Veröffentlichung von Firefox 67.0.1 am 4. Juni sowie Firefox 68 am 9. Juli hat diese Verschiebung keine Auswirkungen. Nachfolgende Versionen erscheinen an ihren bisher geplanten Terminen. Auch Mozillas neuer Android-Browser Fenix wird wie geplant am 25. Juni veröffentlicht werden, lediglich eine Woche später als geplant von der Nightly- auf die Beta-Version der Rendering-Engine GeckoView 68 wechseln.

Der Beitrag Veröffentlichung von Firefox 67 wird verschoben erschien zuerst auf soeren-hentzschel.at.

Textbausteine helfen beim Schreiben von E-Mails und anderen Nachrichten, um immer gleiche Formulierungen (Mit freundlichen Grüßen …) rasch einzufügen. Textbausteine eignen sich aber auch dazu, häufig benötigte Kommandos (ssh name@hostname) oder Code-Anweisungen (// Copyright MeineFirma) effizient einzugeben. Genau diese Aufgabe übernimmt das Mini-Script texpander.sh.

Installation

Das großartigste Merkmal von Texpander besteht darin, dass es sich dabei um ein nur 70 Zeilen kurzes Shell-Script handelt! Ich liebe einfache Lösungen!

https://github.com/leehblue/texpander

Zur Installation laden Sie dieses Script von der GitHub-Seite herunter, speichern es an einem beliebigen Ort (gut geeignet ist das Unterverzeichnis bin, das Sie gegebenenfalls vorher in Ihrem Heimatverzeichnis einrichten) und setzen das Execute-Bit (chmod +x texpander.sh).

Das Script greift auf drei andere Tools zurück, die Sie installieren müssen (hier für Debian/Ubuntu):

sudo apt install xsel xdotool zenity

Zu guter Letzt müssen Sie das Script texpander.sh noch mit einem Tastenkürzel verbinden. Die Vorgehensweise hängt dabei von Ihrem Desktop-System ab. Unter Gnome öffnen Sie in den Einstellungen das Modul Geräte / Tastatur. Am Ende der langen Liste aller Tastenkürzel fügen Sie mit dem Plus-Button ein eigenes Kürzel hinzu, wobei Sie als Befehl den exakten Pfad zum Script angeben. Ich habe mich für das Kürzel Strg+, entschieden.

Textbausteine definieren

So kurz wie das Texpander-Script ist, so einfach ist das Anlegen von Textbausteinen: Jeder Textbaustein wird als Datei im Verzeichnis .texpander gespeichert. Der Dateiname gibt das Kürzel an. Für die eingangs erwähnten freundlichen Grüße richten Sie also die Datei .texpander/mfg mit dem gewünschten Text ein.

Anwendung

Wenn Sie nach der Definition einiger Tastenkürzel die festgelegte Tastenkombination drücken, zeigt texpander.sh einen kleinen Dialog mit der Liste aller Textbausteine an. Durch die Eingabe der Anfangsbuchstaben wählen Sie das gewünschte Kürzel aus, Return fügt es in das gerade aktuelle Programm ein.

texpander.sh verwendet zum Einfügen die Zwischenablage, stellt deren ursprünglichen Inhalt anschließend aber wieder her. Das Script versucht zu erkennen, ob es sich beim aktuellen Programm um ein Terminalfenster handelt. In diesem Fall wird der Text mit Shift+Strg+V eingefügt, sonst mit Strg+V.

Einschränkungen und Probleme

Nicht mit Wayland: Die zur Zeit verfügbaren Programme zur Eingabe von Textbausteinen setzen alle voraus, dass Xorg als Grafiksystem zum Einsatz kommt! Unter Wayland fehlen ganz einfach noch die Schnittstellen, die zur Programmierung derartiger Funktionen erforderlich sind.

Probleme mit mehreren Gnome-Tastaturlayouts: Sofern Sie in Gnome mehrere Tastaturlayouts eingerichtet haben und zwischen diesen wechseln, tritt ein merkwürdiges Problem auf: Solange das erste Layout aktiv ist, funktioniert der Texpander wunderbar. Ist aber ein anderes Layout aktiv, treten beim Einfügen Verzögerungen auf, die durchaus ein, zwei Sekunden betragen können.

Die Ursache des Problems ist aktuell unbekannt, eine Lösung nicht in Sicht. Betroffen sind davon alle Programme, die wie der Texpander auf xdotool zurückgreifen (siehe auch diesen Bug-Bericht). Verändern Sie gegebenenfalls die Reihenfolge der Tastaturlayouts in den Einstellungen. Das aktuell erste Layout ist von dem Problem nicht betroffen, alle weiteren schon.

Alternativen

Als leistungsfähigstes Linux-Tool zum Einfügen von Textbausteinen sowie ganz allgemein für Automatisierungsaufgaben gilt AutoKey. Die Inbetriebnahme und Konfiguration sind aber kompliziert. Bei meinen Tests war zudem die Anwendung fehleranfällig: Immer wieder verschwanden beim Einfügen von Text einzelne Zeichen.

Links

• https://github.com/leehblue/texpander
• https://github.com/autokey/autokey
• https://github.com/bulletmark/libinput-gestures/issues/151

Firefox-Nutzer hatten am Wochenende mit einem Problem zu kämpfen, welches dafür sorgte, dass sämtliche Erweiterungen automatisch deaktiviert waren und auch keine Add-ons installiert oder aktualisiert werden konnten. Für Nutzer, bei denen Firefox 66.0.4 keine Abhilfe schaffte, steht nun mit Firefox 66.0.5 ein weiteres Update bereit.

Aufgrund eines Zertifikat-Problems kam es am Wochenende zu einem Problem, welches zur Deaktivierung sämtlicher Erweiterungen für Nutzer von Firefox, Firefox ESR und Firefox für Android sorgte. Auch die Installation neuer Erweiterungen sowie Aktualisierung von Add-ons verweigerte Firefox.

Mozilla hatte zeitnah in Form eines Hotfixes reagiert, welches über die Studien-Infrastruktur verteilt worden ist, um so schnell viele Nutzer zu erreichen. Schließlich wurde am nächsten Tag dann Firefox 66.0.4 veröffentlicht, um das Problem für all jene Nutzer zu bereinigen, welche durch den Hotfix nicht erreicht werden konnten.

Für Nutzer mit installieter Sicherheits-Software oder aktiviertem Master-Passwort konnte es vorkommen, dass Firefox 66.0.4 keine Wirkung zeigte. Mit Firefox 66.0.5 hat Mozilla jetzt ein weiteres Update nachgelegt, welches das Problem auch für die verbliebenen Nutzer lösen soll. Ein entsprechendes Update der Enterprise-Variante auf Firefox ESR 60.6.3 ist für morgen geplant.

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

Während es sich von selbst versteht, dass veraltete Firefox-Versionen kein Browser-Update mehr erhalten werden, und der originale Hotfix lediglich an Nutzer von Firefox 61 und höher verteilt worden ist, arbeitet Mozilla außerdem an einem angepassten Hotfix für Firefox 60 und niedriger – bis mindestens Firefox 52. Und das, obwohl diese Firefox-Versionen schon lange nicht mehr unterstützt werden.

Der Beitrag Firefox 66.0.5: Mozilla bringt weiteres Update gegen Erweiterungs-Problem erschien zuerst auf soeren-hentzschel.at.

Immer wieder kommt es mal vor, das man bei der Arbeit mit einer Git Repository unbeabsichtigt Dateien in dieses Repository aufnimmt, die dort eigentlich nichts zu suchen haben. Sei es temporäre Dateien, wie zum Beispiel .DS_Store oder .~. Im späteren Verlauf ist es sehr ärgerlich diese Dateien wieder zu entfernen.

In diesem Beitrag möchte ich euch zeigen wir ihr diese Dateien aus der Repository entfernen könnt. Zwei Wege werde ich aufzeigen, einmal wo auch lokal diese Dateien entfernt werden und einmal wo die Dateien lokal bestehen bleiben.

Ausschließen von Dateien

In Git gibt es die Möglichkeiten bestimmte Dateien aus eine Repository auszuschließen. Dafür wurde von den Entwicklern von Git die Datei .gitignore geschaffen. In dieser einfach Textdatei kann man Zeilenweise Ordner, Dateien oder reguläre Ausdrücke aufnehmen um Dateien oder Ordner auszuschließen.

.DS_Store
*.~
...

Da es viele verschiedene Entwicklungsumgebungen und Programmiersprachen gibt und man nicht von allen die temporären Dateien kennen kann, haben sich einige Entwickler die Mühe gemacht, einen Generator für diese Datei zu entwickeln. Diese kann auf der folgenden Seite genutzt werden.

https://www.gitignore.io/

Entfernen von lokalen Dateien und Dateien in der Repository

Im folgenden gehe ich davon aus, dass ihr bereits eine .gitignore Datei angelegt habt. Diese wird jetzt benötigt um die entsprechenden Datei zu finden und zu löschen. Dazu könnt ihr den folgenden Befehl nutzen.

for f in $(cat .gitignore) ; do
  git rm -rf --ignore-unmatch "$f"
done && git add .gitignore && git commit -m "fix temp files" && git push origin master

Als Einzeiler

for f in $(cat .gitignore) ; do git rm -rf --ignore-unmatch "$f"; done && git add .gitignore && git commit -m "fix temp files" && git push origin master

Dieser Befehl findet alle diese Dateien nur, wenn diese bereits gestated wurden. Um die Datei zu finden und zu löschen bevor Sie gestated wurden muss der Befehl ein wenig angepasst werden:

for f in $(cat .gitignore) ; do
  rm -rf "$f"
done

Als Einzeiler

for f in $(cat .gitignore) ; do rm -rf "$f"; done

Bitte nur anwenden, wenn ihr wirklich wisst was ihr tut. Am besten vorher eine Sicherung anlegen

Entfernen Dateien in der Repository und behalten der lokalen Dateien

Als letztes gehen wir jetzt noch drauf ein, wie wir Dateien aus der Repository löschen aber die lokalen behalten. Dazu fügen wir nur eine kleine Option an den oberen Befehl an:

for f in $(cat .gitignore) ; do
  git rm -rf --cached --ignore-unmatch "$f"
done && git add .gitignore && git commit -m "fix temp files" && git push origin master

Als Einzeiler

for f in $(cat .gitignore) ; do git rm -rf --cached --ignore-unmatch "$f"; done && git add .gitignore && git commit -m "fix temp files" && git push origin master

Die Option --cached verhindert das Löschen der lokalen Dateien.

Und das war es auch schon. Jetzt sind wieder nur die wirklich wichtigen Dateien in unsere Repository.

Ab Firefox 67 können Web-Benachrichtigungen nur noch bei verschlüsselter Übertragung genutzt werden. Gleiches gilt ab Firefox 68 für den Zugriff auf Kamera und Mikrofon.

Die verschlüsselte Übertragung von Daten im Web gewinnt immer mehr an Bedeutung. Bereits über 78 Prozent aller von Firefox-Nutzern geladenen Webseiten werden über HTTPS anstelle von HTTP übertragen. Auch die unter anderem von Mozilla ins Leben gerufene Certificate Authority (CA) Let’s Encrypt, welche kostenlos Zertifikate für die Nutzung von HTTPS bereitstellt, trägt einen großen Anteil daran.

Längst sind bestimmte Features nur noch in einem sogenannten gesicherten Kontext nutzbar. Von einem sicheren Kontext spricht man bei der Verwendung von HTTPS, aber auch verschlüsselte WebSocket-Verbindungen (wss://) sowie lokale Ressourcen (wie http://localhost/ oder file://) werden als sicherer Kontext betrachtet.

Ab Firefox 67 erfordern auch sogenannte Web-Benachrichtigungen einen sicheren Kontext. Benachrichtigungen möchte Mozilla in naher Zukunft übrigens auch weniger nervend für den Nutzer machen.

Die getUserMedia-API erlaubt Webseiten den Zugriff auf die Kamera sowie das Mikrofon. Hier gibt es bereits die Einschränkung, dass sich Firefox die Erlaubnis nur in einem sicheren Kontext merken kann, grundsätzlich funktioniert der Zugriff aber auch noch bei unverschlüsselter Verbindung. Ab Firefox 68 wird auch hierfür zwingend ein sicherer Kontext vorausgesetzt.

Der Beitrag Firefox 67/68: Benachrichtungen und Kamera-Zugriff nur noch über HTTPS erschien zuerst auf soeren-hentzschel.at.

Nach fast 7 Monaten komme ich endlich wieder dazu einen Blogbeitrag zu verfassen. In den nächsten Tagen und Wochen, werde ich versuchen meinen Beitragsreihen fortzuführen bzw. zu beenden. Ich möchte mich bei meinen Lesern entschuldigen, das ihr so lange nichts von mir gehört habt.

Kontaktinformationen

Die Kontaktinformationen haben sich verändert. So habe ich meinen alten Jabber Account raktiviert und meinen eignen XMPP Server aufgrund von Zeitmangel eingestellt. Auch gibt es einen aktuellen PGP Key, den es jetzt direkt auf meiner Seite zum Download gibt.

macOS

Zur Zeit ist macOS mein primäres Betriebssystem, was dazu führt, das meine Crux Ports gerade nicht aktuell gehalten werden. Zusätzlich dazu, werden sich meinen Blogbeiträge damit hauptsächlich auf die Nutzung von Linux auf Servern konzentrieren. Ab und zu, werden ich Beiträge zu OpenSource Software in der Verbindung mit iOS und macOS posten.