Immer mehr Webseiten setzen auf sogenannte Web-Benachrichtigungen. Dies verursacht entsprechend auf immer mehr Webseiten Nachfragen, welche von vielen als nervig empfunden werden. Mozilla plant nun Änderungen, damit die Nutzer weniger genervt werden.

Was sind Web-Benachrichtigungen?

Web-Benachrichtungen sind im Prinzip eine gute Sache: Webseiten können den Nutzer auf dem Laufenden halten, zum Beispiel im Falle eines Chats über neue Nachrichten, auch wenn die entsprechende Seite gerade nicht im Vordergrund ist. Ebenfalls gut: Web-Benachrichtungen benötigen die explizite Erlaubnis des Nutzers, Webseiten können den Nutzer also nicht ohne Zustimmung belästigen. Und weil es so praktisch ist, setzen immer mehr Webseiten darauf. Doch genau daraus ergibt sich ein Problem.

Was ist das Problem mit Web-Benachrichtigungen?

Die meisten Webseiten setzen dieses an sich sehr gute Feature falsch ein, weil sie den Benutzer bereits beim ersten Seitenaufruf belästigen, obwohl dieser in den meisten Fällen gar nicht die Absicht hat, Benachrichtigungen zu aktivieren. Kombiniert mit dem Umstand, dass das Ganze mittlerweile auf gefühlt jeder zweiten Webseite der Fall ist, führt dies zu einem hohen Nerv-Faktor der Nutzer, welche solche Dialoge nicht mehr sehen können.

Web-Benachrichtigungen abschalten

Bereits seit Firefox 59 können die Benachrichtigungs-Anfragen komplett abgeschaltet werden. Das ist toll für alle, die wissen, dass sie dieses Feature sowieso nicht nutzen werden. Das eigentliche Problem wird dadurch aber nicht gelöst, weil damit auch dann Anfragen verhindert werden, wenn sie mal wirklich sinnvoll und vom Nutzer gewollt sind.

Was die Zahlen sagen

Dass der Status Quo nicht funktioniert, ist auch durch Telemetrie-Daten belegt. Demnach ist diese Berechtigungs-Anfrage die am meisten gezeigte mit 18 Millionen mal innerhalb eines Monats mit Firefox Beta. Davon wurden weniger als drei Prozent durch den Benutzer positiv beantwortet. Zum Vergleich: Die Mikrofon-/Kamera-Anfrage kommt auf eine Akzeptanz-Rate von über 85 Prozent.

Mozilla möchte das Problem angehen und die Benachrichtigungs-Anfragen wieder sinnvoll machen. Dazu wird Mozilla zwei Experimente durchführen.

Experiment 1

Für Nutzer der Nightly-Version von Firefox ändert Mozilla bis zum 29. April bei aktivem Experiment das Verhalten. In dieser Zeit wird es einer expliziten Nutzer-Interaktion bedürfen, damit es überhaupt zu einer Anfrage kommt. Konkret heißt dies: Ohne Tasten- oder Mausklick gibt es keine Berechtigungs-Anfrage für Benachrichtigungen.

Dabei wird Firefox in den ersten zwei Wochen überhaupt keine Benachrichtigung anzeigen, während in den letzten zwei Wochen ein animiertes Symbol in der Adressleiste angezeigt wird, ohne jedoch direkt den Dialog anzuzeigen. Dieser erscheint erst bei Klick auf das Icon.

Experiment 2

Gleichzeitig denkt Mozilla, dass Nutzer-Interaktion auch noch nicht die perfekte Lösung für das Problem darstellt, und möchte daher mehr darüber lernen, wie Nutzer mit den Dialogen interagieren.

Zu diesem Zweck wird Mozilla in der finalen Version von Firefox 67 etwas mehr Telemetrie-Daten als üblich erheben, um Fragen konkret zu diesen Berechtigungs-Fragen beantworten zu können, was es Mozilla schließlich erlaubt, an Heuristiken zu arbeiten, damit die Dialoge dann angezeigt werden, wenn sie sinnvoll und im Interesse des Nutzers sind.

Die erweiterte Daten-Erhebung über Telemetrie in einer finalen Version von Firefox stellt ein Ausnahme dar, wird nur für kurze Zeit und außerdem nur mit einer begrenzten Zahl der Nutzer durchgeführt.

Der Beitrag Mozilla möchte nervige Benachrichtigungs-Anfragen reduzieren erschien zuerst auf soeren-hentzschel.at.

Cloud geht heute weit über Dateisynchronisation hinaus. Die meisten Menschen nutzen mehrere Endgeräte und haben den Anspruch wichtige Daten auf allen diesen Geräten dabei zu haben und Veränderungen automatisch abzugleichen. Kalender und Aufgaben sind Informationen, die man immer und überall aktuell braucht.

Linux bietet in einer vernetzten Welt keinen Komfort - wohl aber verschiedene Werkzeuge um einen hohen Grad an Vernetzung zu erreichen. In der Serie "Cloud unter Kontrolle" wird genau diese Vernetzung Thema sein. Das Ziel ist eine Lösung, die in etwa dem umfassenden Angebot entspricht, wie es Apple mit den iCloud-Diensten oder Google mit seinen Lösungen bietet. Allerdings unter Kontrolle des Nutzers.

 Serie:

1. Cloud in Eigenregie I: Vorbemerkungen
2. Cloud in Eigenregie II: Basis für Nextcloud wählen
3. Cloud in Eigenregie III: Nextcloud einrichten
4. Cloud in Eigenregie IV: Dateien über die Cloud verwalten
5. Cloud in Eigenregie V: Integration in GNOME
6. Cloud in Eigenregie VI: Kontakte synchronisieren
7. Cloud in Eigenregie VII: Kalender und Aufgaben verwalten
8. Cloud in Eigenregie VIII: RSS Feeds lesen und synchronisieren
9. Cloud in Eigenregie IX: Baustelle Podcasts
10. Cloud in Eigenregie X: Notizen

Nextcloud-Instanzen haben die Kalender-App in der Regel schon vorinstalliert. Sollte dies nicht der Fall sein lässt sich das mit wenigen Klicks über den integrierten App Store nachholen. Im Abschnitt Organisation gibt es die mit "Offiziell" markierte App Calendar. Nach der Installation erscheint in der Menüleiste ein stilisiertes Umschlagkalender-Symbol über den sich die Kalender-Oberfläche öffnen lässt.

Die Web-App bietet eine Tages-, Wochen- und Monatsansicht und es lassen sich mehrere Kalender über diese verwalten. Weiterhin ist es möglich Kalender wie z. B. Feiertagskalender zu abonnieren. Die Einstellungen sind rudimentär gehalten und erlauben lediglich optional die Kalenderwoche einzublenden.

Verbunden mit dem Thema Termine ist der Bereich Aufgaben/ToDo Management. Hier gibt es keine offizielle App, aber die Lösung Tasks. Diese integriert sich in den Kalender und bietet eine Synchronisation via CalDAV an. Dadurch ist der Funktionsumfang zwar nicht so groß wie bei Taskwarrior und ähnlichen Lösungen aber dafür funktioniert dies bei den meisten Betriebssystemen ohne zusätzliche Installationen.

Eine bessere Integration in den Desktop erreicht man natürlich über ein natives Programm. Unter Ubuntu bieten sich hier GNOME Kalender oder Evolution an. Sofern man die GNOME Integration durchgeführt hat erscheinen die Einträge automatisch in der App. Hinzu kommt die automatische Integration in die GNOME Shell.

Die GNOME Kalender Anwendung liefert Ubuntu standardmäßig nicht aus, weshalb man sie aus den Paketquellen nachinstallieren muss:

$ sudo apt-get install gnome-calendar

Die sehr rudimentäre App lässt allerdings keine Aufgabenverwaltung zu. Spätestens wenn man diese Funktionen nutzen möchte lohnt sich daher ein Wechsel auf das deutlich mächtigere Evolution. Dieses hat Ubuntu zu Gunsten von Thunderbird aufgegeben, aber es lässt sich aus den Paketquellen nachinstallieren:

$ sudo apt-get install evolution

Die Oberfläche bietet gleich deutlich mehr Funktionen. Ähnlich wie bei Microsoft Outlook gibt es eine kombinierte Kalender- und Aufgabenansicht, sowie eine separate Aufgabenoberfläche.

Durch die CardDAV Schnittstelle funktioniert dies natürlich auch für andere Lösungen wie KOrganizer oder Thunderbird mit Lightning. Ebenso ist eine Synchronisation auf die mobilen Systeme iOS und Android möglich. In der App-Oberfläche zeigt die Calendar-App dankenswerterweise die passenden CalDAV-Urls an.

Diese Serie soll zeigen wie eine Cloudintegration einfach funktionieren kann. Thunderbird mit seinen umständlichen Extraarbeiten in allen Bereichen (DAV-Schnittstellen, PGP-Support) werden daher hier nicht erklärt.

Bilder:
Einleitungs- und Beitragsbild von IO-Images via pixabay

Vor knapp zwei Jahren hatte ich bereits über den GNOME 3-Window Switcher (Alt+Tab) geschrieben, der standardmäßig gruppierte Fenster anzeigt. Um alle Fenster ungruppiert anzuzeigen, konnte die Erweiterung "Alternatetab" eingesetzt werden. Mit dem frisch veröffentlichten GNOME 3.32 gibt es diese Erweiterung allerdings nicht mehr. Wie der Entwickler nun in seinem Blog schreibt, ist das allerdings auch gar nicht nötig, da die Erweiterung selber nur das Tastaturmapping geändert hat, was grundsätzlich auch über die Einstellungen geht.

Hintergrund: standardmäßig ist Super/Alt+Tab auf "Anwendung wechseln" gemappt statt auf "Fenster wechseln".

Um dies zu ändern, muss man in GNOME 3.32 in die Einstellungen unter Geräte > Tastatur gehen und dort nach "Fenster wechseln" suchen. Mit einem Klick auf den Listeneintrag kann eine neue Tastenkombination vergeben werden, zusätzlich muss das Überschreiben des alten Mappings mit "Ersetzen" bestätigt werden.

Cloud geht heute weit über Dateisynchronisation hinaus. Die meisten Menschen nutzen mehrere Endgeräte und haben den Anspruch wichtige Daten auf allen diesen Geräten dabei zu haben und Veränderungen automatisch abzugleichen. Das Adressbuch ist einer dieser Datenbestände und natürlich lassen sich die Kontakte auch mit Nextcloud verwalten.

Linux bietet in einer vernetzten Welt keinen Komfort - wohl aber verschiedene Werkzeuge um einen hohen Grad an Vernetzung zu erreichen. In der Serie "Cloud unter Kontrolle" wird genau diese Vernetzung Thema sein. Das Ziel ist eine Lösung, die in etwa dem umfassenden Angebot entspricht, wie es Apple mit den iCloud-Diensten oder Google mit seinen Lösungen bietet. Allerdings unter Kontrolle des Nutzers.

 Serie:

1. Cloud in Eigenregie I: Vorbemerkungen
2. Cloud in Eigenregie II: Basis für Nextcloud wählen
3. Cloud in Eigenregie III: Nextcloud einrichten
4. Cloud in Eigenregie IV: Dateien über die Cloud verwalten
5. Cloud in Eigenregie V: Integration in GNOME
6. Cloud in Eigenregie VI: Kontakte synchronisieren
7. Cloud in Eigenregie VII: Kalender und Aufgaben verwalten
8. Cloud in Eigenregie VIII: RSS Feeds lesen und synchronisieren
9. Cloud in Eigenregie IX: Baustelle Podcasts
10. Cloud in Eigenregie X: Notizen

Nextcloud-Instanzen haben die Kontakte-App in der Regel schon vorinstalliert. Sollte dies nicht der Fall sein lässt sich das mit wenigen Klicks über den integrierten App Store nachholen. Im Abschnitt Organisation gibt es die mit "Offiziell" markierte App Contacts. Nach der Installation erscheint in der Menüleiste ein stilisierter Kopf über den sich die Kontakte-Oberfläche öffnen lässt. Diese ist sehr rudimentär gehalten und ermöglicht im Wesentlichen das Anlegen eines neuen Kontaktes und über die Einstellungen unten links den Import eines bestehenden Adressbuchs. Der Import eines ca. 50 Kontakte umfassenden Testsatzes aus einer VCF-Datei klappte problemlos. Es ist über die App-Einstellungen auch möglich mehrere Adressbücher anzulegen.

Über die Web-App ist nun eine Pflege des Adressbuchs möglich. Praktischer ist aber sicherlich die Integration in den Desktop und die Mobilsysteme. Dafür bietet Nextcloud eine CardDAV Schnittstelle.

Unter Ubuntu bietet sich hierfür entweder Evolution an, wenn man eine möglichst umfangreiche PIM-Suite möchte oder GNOME Kontakte, wenn eine simpel gehaltene Oberfläche genügt. Das Programm gehört nicht zum Standardumfang von Ubuntu und muss daher nachinstalliert werden:

$ sudo apt-get install gnome-contacts

Hat man Nextcloud via GNOME Integration eingebunden fragt die GNOME Contacts App beim Start, ob man das Nextcloud-Konto aktivieren möchte.

Anschließend zeigt die sehr minimalistisch gehaltene Oberfläche die zugehörigen Kontakte an.

Durch die CardDAV Schnittstelle funktioniert dies natürlich auch für andere Lösungen wie Evolution (ebenfalls über die GNOME-Integration), KAddressbook oder Thunderbird. Für letzteres werden dazu allerdings noch zusätzliche Addons benötigt. Eine Einbindung in Android und iOS ist ebenso einfach möglich.

Für Android benötigt man die App DAVx⁵, weil Google in Android keine native DAV-Unterstützung implementiert hat. Apple unterstützt hier offene Schnittstellen deutlich besser, weshalb man die Synchronisation ohne zusätzliche App einrichten kann.

Diese Serie soll zeigen wie eine Cloudintegration einfach funktionieren kann. Thunderbird mit seinen umständlichen Extraarbeiten in allen Bereichen (DAV-Schnittstellen, PGP-Support) werden daher hier nicht erklärt.

Bilder:
Einleitungs- und Beitragsbild von IO-Images via pixabay

Eine möglichst einfache Einrichtung der Cloud-Integration ermöglicht es vielen Benutzern diese optimal zu nutzen. GNOME erleichtert dies enorm durch einen Integrationsassistenten in den Systemeinstellungen. Voraussetzung ist eine durchgängige Nutzung von GNOME Anwendungen.

Linux bietet in einer vernetzten Welt keinen Komfort - wohl aber verschiedene Werkzeuge um einen hohen Grad an Vernetzung zu erreichen. In der Serie "Cloud unter Kontrolle" wird genau diese Vernetzung Thema sein. Das Ziel ist eine Lösung, die in etwa dem umfassenden Angebot entspricht, wie es Apple mit den iCloud-Diensten oder Google mit seinen Lösungen bietet. Allerdings unter Kontrolle des Nutzers.

 Serie:

1. Cloud in Eigenregie I: Vorbemerkungen
2. Cloud in Eigenregie II: Basis für Nextcloud wählen
3. Cloud in Eigenregie III: Nextcloud einrichten
4. Cloud in Eigenregie IV: Dateien über die Cloud verwalten
5. Cloud in Eigenregie V: Integration in GNOME
6. Cloud in Eigenregie VI: Kontakte synchronisieren
7. Cloud in Eigenregie VII: Kalender und Aufgaben verwalten
8. Cloud in Eigenregie VIII: RSS Feeds lesen und synchronisieren
9. Cloud in Eigenregie IX: Baustelle Podcasts
10. Cloud in Eigenregie X: Notizen

Die Einrichtung der Integration erfolgt über die GNOME Einstellungen über den Menüunkt Online-Konten. Die Nextcloud Integration wird standardmäßig angeboten. Hier muss die URL der Nextcloud-Instanz, sowie die Logindaten des Kontos angegeben werden. Bei aktivierter Zwei-Faktor-Authentifizierung ist das Passwort durch ein zuvor festgelegtes App-spezifisches Kennwort zu ersetzen.

Anschließend fragt der Assistent ab welche Bereiche integriert werden sollen. Die Datei-Integration beruht auf der WebDAV Schnittstelle, weshalb die Dateien über eine Netzwerkfreigabe eingehängt werden. Dadurch stehen die Dateien nur bei einer bestehenden Internetverbindung zur Verfügung. Daher ist die Verwendung des richtigen Sync-Clients immer vorzuziehen (siehe: Cloud in Eigenregie IV: Dateien über die Cloud verwalten) und dieser Punkt zu deaktivieren.

Die aktivieren Onlinekonten werden anschließend in den Einstellungen oben aufgelistet.

Die Integration durch dieses Assistenten funktioniert nur für die GNOME Anwendungen Kontakte, Kalender und die PIM-Suite Evoluton. Eine automatische Integration in den Ubuntu-Standardclient Thunderbird erfolgt nicht.

Die Integrationsroutine erfolgt ansonsten vorbildlich und wer primär mit GNOME-Anwendungen arbeitet bekommt hier eine gute Cloudintegration von Dateien, Dokumenten, Kontaktern und Kalenderdaten ohne sich mit den Details beschäftigen zu müssen.

Nachteiligt wirkt sich hier erneut die Zersplitterung des Linux-Ökosystems aus. Die vorliegende Integration funktioniert so nur für GNOME und die direkt integrierten Applicationen. Drittprogramme wie Thunderbird sind außen vor. Andere Desktopumgebungen haben teilweise andere Assistenten.

Bilder:
Einleitungs- und Beitragsbild von IO-Images via pixabay

Der automatische und unkomplizierte Abgleich von Dateien über die Cloud ist die ursprüngliche Primärfunktion der meisten Clouddienste. Die Einrichtung eigentlich kein Problem und bei macOS und Windows haben mit iCloud und OneDrive bereits vorinstallierte Angebote. Der folgende Artikel zeigt die Installation und Einrichtung mit Nextcloud.

Linux bietet in einer vernetzten Welt keinen Komfort - wohl aber verschiedene Werkzeuge um einen hohen Grad an Vernetzung zu erreichen. In der Serie "Cloud unter Kontrolle" wird genau diese Vernetzung Thema sein. Das Ziel ist eine Lösung, die in etwa dem umfassenden Angebot entspricht, wie es Apple mit den iCloud-Diensten oder Google mit seinen Lösungen bietet. Allerdings unter Kontrolle des Nutzers.

 Serie:

1. Cloud in Eigenregie I: Vorbemerkungen
2. Cloud in Eigenregie II: Basis für Nextcloud wählen
3. Cloud in Eigenregie III: Nextcloud einrichten
4. Cloud in Eigenregie IV: Dateien über die Cloud verwalten
5. Cloud in Eigenregie V: Integration in GNOME
6. Cloud in Eigenregie VI: Kontakte synchronisieren
7. Cloud in Eigenregie VII: Kalender und Aufgaben verwalten
8. Cloud in Eigenregie VIII: RSS Feeds lesen und synchronisieren
9. Cloud in Eigenregie IX: Baustelle Podcasts
10. Cloud in Eigenregie X: Notizen

Die ersten drei Teile der Serie beinhalteten eher abstrakte Überlegungen, nun geht es um die konkrete Integration in einen Linux-Desktop. Als Beispiel soll hier Ubuntu herangezogen werden, da es in der zersplitterten Linux-Welt immer noch den Quasi-Standard bildet.

Manche Distributionen bieten den Nextloud Client bereits in den Paketquellen - Ubuntu leider nicht. Hier gibt es nur den ownCloud-Client, den man eigentlich auch verwenden kann, da es sich hier faktisch um das gleiche Programm mit unterschiedlichem Branding handelt. Für eine konsistente Cloud-Demonstration soll hier aber auf eine reine Nextcloud-Lösung zurückgegriffen werden.

Zuerst muss daher das PPA hinzugefügt werden:

$ sudo add-apt-repository ppa:nextcloud-devs/client

Anschließend lässt sich der Nextcloud-Client installieren. Bei Distributionen ohne installiertes Qt müssen auch die Bibliothek installiert werden, weshalb man insgesamt ca. 200 MB Festplattenspeicher benötigt.

$ sudo apt-get install nextcloud-client

Anschließend muss der Client eingerichtet werden. Beim ersten Start fragt es für die Anmeldung notwendigen Informationen ab. Neben der URL sind dies die Anmeldedaten. Da wir im vorherigen Schritt eine Zwei-Faktor-Authentifizierung eingerichtet haben ist eine Anmeldung per App-Token notwendig. Dazu muss innerhalb der Nextcloud unter Einstellung / Sicherheit ein spezifisches App-Kennwort generiert werden.

Anschließend erfragt das Programm wo der Standard-Synchronisations-Ordner abgelegt werden soll. Normalerweise ist dies Nextcloud in eurem Home-Verzeichnis. Zudem kann man entscheiden, ob bereits alle Daten synchronisiert werden sollen.

Nun sollte man die Einstellungen kontrollieren. Sinnigerweise ist der Client beim Systemstart zu starten und monochrome Icons sorgen für eine bessere Integration in den Ubuntu Desktop.

Eine Besonderheit von ownCloud / Nextcloud ist, dass der Client problemlos verschiedene Ordner synchronisieren kann. Dazu wählt man Ordner-Synchronisation hinzufügen und legt ein Synchronisationspaar aus lokalem Ordner und Ordner auf der ownCloud fest.

Je nach Größe der ownCloud lässt sich dadurch fast jeder Ordner im Home synchronisieren.

Zum Abschluss kann man noch den Synchronisationsstatus im Dateimanager einblenden. Das dafür notwendige Paket hängt vom Dateimanager ab. Die Integration ist verfügbar für Dolphin, Caja, Nemo und Nautilus. Da das vorliegende Beispielsystem ein normales Ubuntu ist benötigt man hier noch das Paket:

$ sudo apt install nextcloud-client-nautilus

Anschließend zeigen kleine Symbole auf den Dateien und Ordner der eingerichteten Sync-Paare den Status an.

Bilder:
Einleitungs- und Beitragsbild von IO-Images via pixabay

Mozilla hat mit Firefox 66.0.2 ein Update außer der Reihe für Firefox 66 veröffentlicht und behebt damit mehrere Probleme der Vorgängerversion.

Download Mozilla Firefox 66.0.2

Nachdem die vor wenigen Tagen veröffentlichte Version Firefox 66.0.1 ein planmäßiges Sicherheits-Update in Zusammenhang mit Pwn2Own darstellte, hat Mozilla nun mit Firefox 66.0.2 das erste Bugfix-Update für Firefox 66 veröffentlicht.

Mit dem Update behebt Mozilla eine mögliche Absturzursache auf Windows. Außerdem sorgt ein Fehler in Windows 10 für einen anderen möglichen Browser-Absturz, den Mozilla mit Firefox 66.0.2 umgeht, da Microsoft den Fehler erst im Juni-Update beheben möchte.

Darüber hinaus werden Kompatibilitätsprobleme mit Microsoft Office 365, Apple iCloud sowie IBM WebMail behoben. Die Probleme haben ihre Ursache in einer Änderung des Event-Handlings von Firefox. Auch in diesem Fall liegt nicht tatsächlich ein Fehler in Firefox vor, Mozilla umgeht viel mehr auch hier Probleme Dritter, indem für die genannten Webseiten temporär das alte Verhalten wiederhergestellt wird, bis diese ihren Code korrekt implementiert haben.

Der Beitrag Mozilla veröffentlicht Firefox 66.0.2 erschien zuerst auf soeren-hentzschel.at.

Bei der Nutzung der Bourne-again shell, kurz Bash, wird über die eingegebenen Kommandos Buch geführt. Dies ermöglicht es auf Befehle zurückzugreifen, welche bereits eingeben wurde. Auf die History kann mit den Cursor-Tasten Hoch und Runter zugegriffen werden.

Diese Vorgehensweise ist natürlich nur solange praktisch, wenn der gesuchte Befehl in letzter Zeit eingegeben wurde. Gespeichert wird die History im Home-Verzeichnis des jeweiligen Nutzers in einer Datei mit dem Namen .bash_history. Nun könnte der geneigte Nutzer auf die Idee kommen diese Datei einfach nach dem gesuchten Befehl zu durchforsten:

cat .bash_history | grep "befehl123"

Einfacher ist es allerdings auf die eingebaute Suchfunktion der Bash zurückzugreifen. Aktiviert wird diese mittels der Tastenkombination Strg + R. Danach kann der Suchbegriff eingeben werden und dem Nutzer werden Vorschläge aus der Bash-History angezeigt. Sagt einer dieser Vorschläge zu, kann er mit einem Druck auf die Enter-Taste bestätigt werden. Abgebrochen werden kann die Suche mittels der Tastenkombination Strg + C.

Wieder einmal hat der jährlich stattfindende Pwn2Own-Wettbewerb Sicherheitslücken in diversen Browsern und anderen Softwares offengelegt. Mozilla hat wie immer zügig reagiert und ein Sicherheitsupdate auf Firefox 66.0.1 veröffentlicht.

Wie jedes Jahr fand auch in diesem Jahr wieder der Pwn2Own-Wettbewerb statt, ein Wettbewerb, bei dem es darum geht, Sicherheitslücken in Browsern und anderen Softwares zu finden. Ein schnelles Update so kurz nach Veröffentlichung von Firefox 66 war also erwartet worden.

Denn auch dieses Jahr konnten wieder einige Sicherheitslücken im Rahmen von Pwn2Own demonstriert werden. Auch Firefox konnte erfolgreich überwunden werden. Zwei Sicherheitslücken in IonMonkey, dem JIT-Compiler von Firefox, wurden gefunden, beide stuft Mozilla als kritisch ein. Ein Update ist daher dringend empfohlen.

Der Beitrag Pwn2Own 2019: Mozilla veröffentlicht schnelles Update auf Firefox 66.0.1 erschien zuerst auf soeren-hentzschel.at.

Mozilla hat Firefox 66 veröffentlicht. Auch Firefox 66 ist wieder randvoll gefüllt mit Neuerungen. Dieser Artikel fasst die wichtigsten Neuerungen zusammen.

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

Mehr Sicherheit für Firefox-Nutzer

Geschlossene Sicherheitslücken

Auch in Firefox 66 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 66 daher für alle Nutzer dringend empfohlen.

Doppelt so viele Content-Prozesse

Die Multiprozess-Architektur von Firefox trennt Browser- und Content-Prozesse voneinander, wobei sich mehrere Tabs in der Regel einen Content-Prozess teilen, da Firefox standardmäßig bisher nur vier Content-Prozesse aktiviert hat. Eine Erhöhung der Content-Prozesse verbessert die Sicherheit, Stabilität und Reaktionsfreudigkeit des Browsers, führt aber auch zu einem erhöhten Ressourcen-Verbrauch, da jeder Prozess einen gewissen Ressourcen-Overhead mit sich bringt. Diesen Ressourcen-Overhead versucht Mozilla bestmöglich zu reduzieren, denn langfristig ist das Ziel, dass jede Seite in ihrem eigenen Prozess läuft. In Firefox 66 wurde die standardmäßig aktivierte Zahl der Content-Prozesse erst einmal von vier auf acht verdoppelt.

Bessere Sicherheits-Warnungen

Mozilla hat die Sicherheits-Warnungen von Firefox überarbeitet, um diese leichter verständlich für den Nutzer zu machen. Welche Überlegungen hinter den jeweiligen Änderungen stehen, wurden in diesem Artikel (engl.) beschrieben.

Für selbst signierte Zertifikate muss nicht länger über mehrere Klicks und einen Dialog eine Ausnahme erstellt werden, hier wurde der Weg vereinfacht und zwei Klicks genügen nun.

Außerdem erkennt Firefox nun Man-in-the-Middle-Unterbrechungen (MITM) von HTTPS-Verbindungen und zeigt den Namen des verursachenden Zertifikates an. Gerade sogenannte Sicherheits-Software ist bekannt dafür, ganz im Stile einer Schadsoftware einen MITM-Angriff auf die Verbindung auszuführen, was die Sicherheit vermeintlich verbessern sollte, in der Realität aber immer wieder für Verbindungs-Probleme bei Firefox-Nutzern sorgt.

Weniger Stress durch Authentifizierung-Dialoge

Eine beliebte Masche unseriöser Webseiten ist es, Nutzer durch ständige Authentifizierungs-Dialoge auf einer Seite gefangen zu halten. Da diese den Tab blockieren, ist es nicht möglich, den Tab zu schließen, solange solche Dialoge erscheinen. Spätestens nach dem dritten Dialog ist ab sofort Schluss. Die Anzahl kann in about:config über prompts.authentication_dialog_abuse_limit konfiguriert werden. Zwar ist die Einstellung nicht neu, allerdings griff diese in vielen Fällen nicht, weswegen Mozilla seine Heuristiken hierfür in Firefox 66 verbessert hat.

Passwortlose Sicherheit: Unterstützung für Windows Hello

Firefox 66 unterstützt Windows Hello. Voraussetzung ist das kommende April-Update von Windows 10. Damit ist eine passwortlose Authentifizierung durch Gesichtserkennung, Fingerabdruck oder Sicherheits-Schlüssel auf Webseiten möglich, sofern von diesen unterstützt. Weitere Informationen (engl.) dazu gibt es im Mozilla Security Blog.

Automatische Wiedergabe von Audio-Inhalten verhindern

Firefox 66 kann die automatische Wiedergabe von Audio-Inhalten verhindern. Dies schließt Videos ein, welche Ton von sich geben. Dabei folgt Firefox einem sogenannten User-Gesten-Aktivierungs-Modell, bei welchem die automatische Wiedergabe von Audio zunächst deaktiviert ist, aber aktiviert wird, wenn der Nutzer mit der Seite interagiert.

Ein Beispiel: Der Nutzer klickt auf einer Webseite den Link zu einem YouTube-Video an. Firefox verhindert die automatische Wiedergabe des Videos. Der Nutzer klickt dann auf YouTube ein anderes Video an. Da angenommen werden kann, dass sich der Nutzer bewusst auf der Webseite bewegt und das Video anklickt hat, um es abzuspielen, wird dieses Video automatisch wiedergegeben und die Wiedergabe nicht blockiert.

Diese Neuerung ist zunächst nur für 25 Prozent der Nutzer standardmäßig aktiviert und soll im Laufe der nächsten zwei Wochen für 100 Prozent der Nutzer ausgerollt werden, sofern keine Probleme auftreten.

In der Zwischenzeit kann das neue Feature aber bereits über die Firefox-Einstellungen aktiviert werden. Dort ist es auch möglich, Ausnahmen zu verwalten.

Scrolling ohne Sprünge während Ladevorgang

Mozilla hat in Firefox 66 sogenanntes Scroll Anchoring implementiert. Das Problem, welches Mozilla damit behebt, ist besonders von bildlastigen Webseiten bekannt: Man lädt eine Webseite und scrollt zu einer bestimmten Stelle, bevor Firefox die Möglichkeit hatte, die Webseite komplett zu laden. Plötzlich tritt an diese Stelle ein anderer Inhalt, weil Firefox weitere Bilder geladen hat, was die Position des gesamten Inhaltes verschiebt. Die Folge: Der Nutzer muss erneut scrollen, um wieder an die gewünschte Stelle zu kommen. Ähnliches gilt für das Öffnen eines Links mit Anker (#), während Firefox noch damit beschäftigt ist, die Inhalte zu laden.

Mit dem in Firefox 66 implementierten Scroll Anchoring ist dies anders. Firefox lädt wie bisher auch alle Ressourcen wie Bilder, verändert dabei aber nicht mehr die Position. Für den Nutzer entsteht nicht länger ein Sprung des Inhalts.

Startseite privater Fenster erhält Suchfunktion

Private Fenster in Firefox schützen die Privatsphäre der Nutzer, da Firefox in diesem Modus keine Chronik, Suchanfragen, Cookies sowie temporäre Dateien speichert. Außerdem ist in diesem Modus der Tracking-Schutz standardmäßig aktiviert, der Referrer wird standardmäßig gekürzt und Webseiten, welche nicht über HTTPS aufgerufen werden, werden als unsicher markiert.

Mozilla hat die Startseite privater Fenster überarbeitet und dabei die Informationen nicht nur kompakter dargestellt, auch gibt es hier nun ein Suchfeld, über welches die vom Benutzer eingestellte Standard-Suchmaschine genutzt werden kann, um im Web nach Informationen zu suchen.

Der Informations-Block enthält außerdem einen Link zu einem neuen Hilfe-Artikel, welcher mit diversen Mythen über private Fenster aufräumt und deutlich macht, was private Fenster nicht leisten.

Verbesserte Unterstützung lokaler UTF-8-Dateien

UTF-8-kodierte HTML- und Plaintext-Dateien, welche über das file://-Protokoll geladen werden, werden nun von Firefox automatisch als solche erkannt, das heißt auch ohne UTF-8-BOM und ohne meta-charset-Angabe. Mit anderen Worten: Lokal geladene Dateien haben nicht länger Umlaut-Probleme.

Unterstützung für Apple MacBook Pro Touch Bar

Mit der Touch Bar besitzt das MacBook Pro von Apple eine berührungsempfindliche Leiste, über welche ein Schnellzugriff auf anwendungsspezifische Funktionen möglich ist. Mit Firefox 66 erhält erstmals auch der Mozilla-Browser Unterstützung für die Touch Bar.

Konkret stellt Firefox dabei standardmäßig die folgenden Funktionen bereit: Seite zurück, Seite neu laden, Adressleiste fokussieren, als Lesezeichen setzen respektive entfernen, neuen Tab öffnen sowie Seite teilen.

Mozilla arbeitet bereits daran, dass der Anwender die Touch Bar über die entsprechende sichtbare Oberfläche von Apple macOS anpassen kann. In der Zwischenzeit können Nutzer aber bereits über about:config Anpassungen vornehmen.

Experimente für den neuen Tab

Die Seite, die standardmäßig beim Öffnen eines neuen Tabs erscheint, enthält diverse Bereiche wie Vorschaubilder der meistbesuchten Seiten, aktuell besuchte oder als Lesezeichen gesetzte Seiten oder auch Pocket-Empfehlungen. Pocket ist ein Dienst von Mozilla. Mozilla experimentiert in Form verschiedener Layouts mit einem Teil der Nutzer mit einer verbesserten Darstellung von Pocket-Inhalten. Wenn einzelne Nutzer also eine veränderte Darstellung bemerken, hängt dies damit zusammen. Der Nutzer kann jederzeit über die Firefox-Einstellungen im Abschnitt Startseite aus den Experimenten aussteigen.

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.

Während die offizielle Ausrollung für erste Nutzer erst mit Firefox 67 erfolgen wird, wird WebRender bereits für 0,075 Prozent der Nutzer im Zeitraum zwischen dem 25. März und dem 15. April aktiviert werden, um Stabilitäts- und Performance-Daten der Release-Population zu erhalten und damit die größere Ausrollung in Firefox 67 zu unterstützen.

Die Zielgruppe für WebRender in Firefox 66 respektive 67 sind ausschließlich Nutzer, welche Windows 10 als Betriebssystem sowie eine halbwegs moderne Grafikkarte von Nvidia einsetzen. Weitere Konfigurationen folgen mit weiteren Firefox-Updates.

Verbesserungen für Firefox-Erweiterungen (WebExtensions)

Tastatur-Kommandos von Erweiterungen können geändert werden

In einigen Firefox-Erweiterungen ist es möglich, diverse Aktionen per Tastatur auszuführen. Nicht immer ist die Wahl eines Tastatur-Kommandos dabei für jeden Nutzer optimal. Zwar konnten Erweiterungen bisher eine eigene Oberfläche implementieren, damit Nutzer die Tastatur-Kommandos ändern können, davon hatten allerdings die wenigsten Erweiterungen Gebrauch gemacht. Ab Firefox 66 können Nutzer die Tastatur-Kommandos sämtlicher Erweiterungen ändern, ohne dass die Erweiterungen hierfür eine eigene Oberfläche implementieren müssen.

Performance-Verbesserungen des Storage-Backends

Mozilla hat ein neues Storage-Backend für Firefox-Erweiterungen implementiert, welches in signifikanten Performance-Verbesserungen und gleichzeitig reduziertem Speicherverbrauch resultiert. Davon profitieren insbesondere Erweiterungen, welche einen kleinen Teil vieler gespeicherter Daten ändern müssen, was insbesondere auf Werbeblocker zutrifft.

Sonstige Neuerungen für Firefox-Erweiterungen

Natürlich gab es auch wieder Verbesserungen der Erweiterungs-Schnittstellen. So sind Kontextmenüs für Lesezeichen beispielsweise nun auch in der Sidebar und in der Bibliothek zu sehen. Weitere Neuerungen an der WebExtension-Front lassen sich hier nachlesen.

Angepasste Willkommens-Seite nach Firefox-Installation über AMO

Besucht jemand Mozillas Erweiterungs-Seite addons.mozilla.org (AMO) mit einem anderen Browser als Firefox, wird auf der Seite angeboten, Firefox herunterzuladen. Installiert der Nutzer darüber Firefox, startet Firefox bisher mit der regulären Willkommens-Seite.

Ab Firefox 66 hat Firefox die Möglichkeit, das Add-on, auf dessen Detail-Seite man sich befunden hat, zu erkennen und eine angepasste Willkommens-Seite anzuzeigen. Installiert der Nutzer darüber Firefox, kann Firefox den Nutzer dann statt mit der üblichen Willkommens-Seite mit einer Installations-Möglichkeit für das Add-on begrüßen, welches sich der Nutzer zuvor angesehen hatte.

Verbesserungen der Webplattform

AV1 für weitere Plattformen

Seit Firefox 65 unterstützt der Mozilla-Browser den neuen Video-Codec AV1, allerdings nur für Nutzer einer 64-Bit-Version von Firefox. Ab Firefox 66 wird auch die 32-Bit-Version von Windows sowie das Apple-Betriebssystem macOS unterstützt.

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

In Zusammenhang mit dem in Firefox 66 implementierten Scroll Anchoring wurde auch die CSS-Eigenschaft overflow-anchor implementiert.

Die CSS-Eigenschaften grid-template-rows und grid-template-columns können jetzt auch animiert werden.

Firefox ist außerdem der erste Browser, der die CSS-Eigenschaften overflow-inline und overflow-block unterstützt.

Der Attribut-Selektor-Modifier s wurde implementiert, um Elemente basierend auf ihrem Attribut ungeachtet der Groß-Kleinschreibung zu finden.

Die neue JavaScript-API MediaDevices.getDisplayMedia() erlaubt das Teilen des Bildschirm-Inhaltes.

Um die Ladezeit von Webseiten zu verbessern, wurde die Priorität von setTimeout()- und setInterval()-Aufrufen reduziert.

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

Neuerungen für Webentwickler

Die Icons der Entwickler-Werkzeuge wurden überarbeitet und passen nun besser zum Photon-Design von Firefox Quantum.

Vom Tracking-Schutz blockierte Ressourcen haben bisher zwei unterschiedliche Warnungen in der Webkonsole generiert, diese wurden zusammengefasst.

Die Methoden alert(), prompt() und confirm() funktionieren nach langer Zeit wieder im Responsive Design Modus.

Der Inspektor ist jetzt auch mit pausiertem Debugger vollständig nutzbar.

Enterprise Features

Die Seite about:policies merkt sich jetzt die Scroll-Position, wenn zwischen den verschiedenen Reitern gewechselt wird.

Firefox 66 unterstützt eine neue Policy zum Festlegen der mindestens erforderlichen sowie eine neue Policy zur maximal unterstützten TLS-Version. Die Policy zum Überprüfen beim Firefox-Start, ob Firefox der Standard-Browser ist, lässt sich nicht mehr nur nutzen, um die Prüfung zu verhindern, sondern jetzt auch, um diese zu erzwingen.

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

Sonstige Neuerungen in Firefox 66

Bei entsprechend vielen geöffneten Tabs zeigt Firefox in der Tableiste ein Pfeil-Symbol an, welches alle geöffneten Tabs auflistet. Hier gibt es einen neuen Eintrag „Tab suchen“, der automatisch ein „%“ in die Adressleiste einfügt – mittels diesem Operator können geöffnete Tabs über die Adressleiste durchsucht werden. Dieses unbekannte Feature besitzt Firefox seit vielen Jahren und durch diese Änderungen wird dieses Feature dem einen oder anderen Nutzer bekannt, der diese Funktion bisher noch nicht kante.

In den Firefox-Einstellungen zeigt Firefox bei Verwendung des permanenten privaten Modus nun einen Hinweis an, wieso die Cookie-Einstellungen nicht verändert werden können (da sich dies ja automatisch ergibt).

Auf Linux ist die System-Titelleiste nun entsprechend der Gnome-Richtlinien standardmäßig deaktiviert. Außerdem wurde ein Performance-Problem behoben, welches manche Linux-Nutzer in Zusammenhang mit dem Download-Panel hatten.

War die versteckte Einstellung privacy.firstparty.isolate auf true gestellt, hatte die Pocket-Integration nicht funktioniert. Dies gehört der Vergangenheit an.

Das dunkle sowie das helle Firefox-Theme überschreiben jetzt die System-Einstellung für die Akzentfarbe der Titelleiste unter Windows 10.

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

Der freie Webserver Nginx beherrscht nicht nur das gewöhnliche Ausliefern von Daten über HTTP und HTTPS, sondern verfügt daneben über weitere Module. Mit einem dieser Module kann WebDAV für eine Ressource bereitgestellt werden. Dazu muss die Konfiguration der jeweiligen Seite unter /etc/nginx/sites-available/ angepasst werden. In diesem Beispiel wäre dies:

nano /etc/nginx/sites-available/example

Zur dieser Konfigurationsdatei wird folgende Konfiguration hinzugefügt:

server {
        listen   443 ssl;
        listen [::]:443 ssl;

        ssl_certificate /etc/letsencrypt/live/example.org/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/example.org/privkey.pem;

        root /var/www/example;

        server_name example.org;

        location / {
                dav_methods     PUT DELETE MKCOL COPY MOVE;
                dav_ext_methods   PROPFIND OPTIONS;
                dav_access    user:rw group:rw all:rw;

                autoindex     on;
        }
}

In diesem Fall wird für die Domain example.org die WebDAV-Unterstützung aktiviert. Dateien können hierbei ohne weitere Authentifizierung herunter- und hochgeladen werden. Soll WebDAV abgesichert werden, so geschieht das über den Basic authentication. Dazu wird dem location-Part folgendes hinzugefügt:

auth_basic "restricted";
auth_basic_user_file /var/www/example/.htpasswd;

Die .htpasswd-Datei kann mit dem Tool htpasswd erstellt werden:

htpasswd -c .htpasswd nutzer1

Bei der Nutzung wird das gewünschte Passwort erfragt. Soll ein weiterer Nutzer hinzugefügt werden, so muss der Parameter -c entfernt werden:

htpasswd .htpasswd nutzer2

Anschließend wird die Konfiguration von Nginx mittels:

service nginx reload

aktualisiert. Danach kann WebDAV für die Ressource verwendet werden.

Der Enterprise Policy Generator richtet sich an Administratoren von Unternehmen und Organisationen, welche Firefox konfigurieren wollen. Damit löst die Erweiterung den bekannten CCK2 Wizard in der Ära Firefox Quantum ab. Die neue Version 4.4 macht den Enterprise Policy Generator fit für Firefox 66, Firefox Beta 67 und Firefox ESR 60.6.

Download Enterprise Policy Generator für Firefox

Mit Firefox 60 und Firefox ESR 60 hat Mozilla die sogenannte Enterprise Policy Engine eingeführt. Die Enterprise Policy Engine erlaubt es Administratoren, Firefox über eine Konfigurationsdatei zu konfigurieren. Der Vorteil dieser Konfigurationsdatei gegenüber Group Policy Objects (GPO) ist, dass diese Methode nicht nur auf Windows, sondern plattformübergreifend auf Windows, Apple macOS sowie Linux funktioniert.

Zwar steht diese Erweiterung in keiner direkten Verbindung zum bekannten CCK2 Wizard, teilt aber die grundlegende Idee vom CCK2 Wizard, welcher in Firefox Quantum nicht mehr funktioniert. Der Enterprise Policy Generator wurde als Nachfolger vom CCK2 Wizard konzipiert – nur eben für Firefox Quantum und Enterprise Policies. Die Firefox-Erweiterung hilft bei der Zusammenstellung der sogenannten Enterprise Policies, so dass kein tiefergehendes Studium der Dokumentation und aller möglichen Optionen notwendig ist und sich Administratoren die gewünschten Enterprise Policies einfach zusammenklicken können. Mehr Informationen gibt es auf der Info-Seite zum Enterprise Policy Generator.

Neuerungen Enterprise Policy Generator 4.4.0

Wie immer gemeinsam mit neuen Firefox-Versionen steht auch eine neue Version des Enterprise Policy Generators zur Verfügung.

Die Policy zum Überprüfen des Standard-Browsers beim Firefox-Start erlaubt nicht länger nur das Abschalten, sondern jetzt auch das Erzwingen der Überprüfung. Diese Policy wird ab Firefox 66 respektive Firefox ESR 60.6 unterstützt.

Die Beschreibung der DisableFirefoxStudies-Policy wurde geändert, um kenntlich zu machen, dass damit nicht nur sogenannte Shield-Studien deaktiviert werden, sondern auch Feature-Empfehlungen.

Außerdem wurde die Unterstützung für diverse neue Policies hinzugefügt, welche allesamt ab Firefox 67 funktionieren, nämlich eine Policy zum Aktivieren oder Deaktivieren der Netzwerk-Anmeldeseite, eine Policy zum Aktivieren oder Deaktivieren von DNS-Prefetching, eine Policy zum Aktivieren oder Deaktivieren automatischer Erweiterungs-Updates sowie eine Policy zum Hinzufügen eines benutzerdefinierten Menü-Eintrages im Hilfe-Menü. Die Policy zum Hinzufügen von Suchmaschinen unterstützt außerdem jetzt auch die POST-Methode.

Roadmap

Wer sich für die Pläne der kommenden Versionen interessiert, findet hier die aktuelle Roadmap. Auch können an dieser Stelle Vorschläge für Verbesserungen gemacht werden.

Entwicklung unterstützen

Wer die Entwicklung des Add-ons unterstützen möchte, kann dies tun, indem er der Welt vom Enterprise Policy Generator erzählt und die Erweiterung auf addons.mozilla.org bewertet. Auch würde ich mich sehr über eine kleine Spende freuen, welche es mir ermöglicht, weitere Zeit in die Entwicklung des Add-on zu investieren, um zusätzliche Features zu implementieren.

Der Beitrag Firefox: Enterprise Policy Generator 4.4 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Barbara Bermes ist Produktmanagerin bei Mozilla und für Mozillas Mobile-Produkte verantwortlich. Im Interview mit soeren-hentzschel.at spricht sie über Marktanteile, Firefox, die neuen Android Components, Fenix und mehr.

Der Beitrag Interview mit Barbara Bermes, Product Manager Mozilla Mobile erschien zuerst auf soeren-hentzschel.at.

Diesmal stand ich vor einem interessanten Problem: Die hinterlegten Verbindungen unter “Mit Server verbinden” wollte ich löschen. Allerdings gibt es in diesem Fenster keine Möglichkeit diese “History” zu leeren. Aber es ist ja nicht Linux wenn es nicht doch eine Lösung geben würde….

/home/username/.config/nautilus/servers

in dieser Datei im XML Format sind die benutzten Verbindungen hinterlegt. Und hier kann man diese auch entfernen.
In dieser Datei müssen die Werte zwischen (bzw. inklusiv) Bookmark entfernt werden.

Die Linux-Distribution Pop!_OS ist von Ubuntu abgeleitet und wird von der amerikanischen Firma system76 entwickelt. Diese Firma verkauft Notebooks, auf denen standardmäßig Pop!_OS installiert ist. Im Vergleich zu anderen Distributionen ist Pop!_OS besonders gut für Notebooks mit NVIDIA-Grafik optimiert.

Ursprünglich dachte ich, Pop!_OS sei nur ein weiterer Ubuntu-Klon mit modifiziertem Gnome-Desktop und integrierten NVIDIA-Treibern. Seit ich die Distribution auf mein neues Lenovo-P1-Notebook installiert habe, weiß ich, dass Pop!_OS weit mehr Eigenheiten hat.

Varianten

Pop!_OS steht aktuell in den Versionen 18.04 LTS und 18.10 sowie in jeweils zwei Varianten zur Auswahl. Diese beiden Varianten unterscheiden sich darin, ob die NVIDIA-Treiber bereits inkludiert sind oder nicht. Ich habe für meinen Tests Pop!_OS 18.10 in der NVIDIA-Variante verwendet.

Notebook-spezifische Vorbereitungsarbeiten

Vor der Installation von Pop!_OS auf meinem Lenovo P1 habe ich das auf einer zweite SSD befindliche Windows aktualisiert und dann ein BIOS-Update durchgeführt (siehe auch diesen heise-Artikel).

Des Weiteren habe ich zwei BIOS-Optionen verändert:

• UEFI Secure Boot = No

• F1-F12 as Primary Keys = Enabled

Die erste Option ist zwingend erforderlich, weil Secure Boot in Kombination mit den nicht GPL-kompatiblen NVIDIA-Treibern unmöglich ist.

Die zweite Option entspricht meinen Gewohnheiten. Ich will die Funktionstasten als solche verwenden (F1 bis F12). In meiner Emacs-Konfiguration sind diese Tasten alle mit häufig verwendeten Funktionen verbunden.

Für die Installation von Pop!_OS ist es hingegen nicht erforderlich, Veränderungen am Grafiksystem durchzuführen. Ich habe die Einstellung Graphics Device = Hybrid Graphics also belassen und nicht auf Discrete umgestellt.

Installation

Bei der Installation lautet das Motto von Pop!_OS: Alles oder nichts. Es gibt nur zwei Installationsvarianten:

• Clean Install verwendet die gesamte Festplatte. (Wenn es mehrere Festplatten/SSDs gibt, können Sie das gewünschte Gerät auswählen.) Diese Variante eignet sich nur, wenn Sie keine Rücksicht auf vorhandene Betriebssysteme nehmen müssen. Sie haben keine Wahlmöglichkeiten bei der Partitionierung. Standardmäßig richtet Pop!_OS eine relativ große Swap-Partition, eine EFI- oder eine boot-Partition sowie eine Datenpartition ein, die die restliche Festplatte/SSD ausfüllt (ext4-Dateisystem). Immerhin können Sie zum Schluss entscheiden, ob das Dateisystem verschlüsselt werden soll oder nicht.

• Custom (Advanced): Hinter dieser Option verbirgt sich das andere Extrem. Wenn Sie sich dafür entscheiden, müssen Sie sich um die Partitionierung selbst kümmern. Das Pop!_OS-Installationsprogramm öffnet dazu GParted, Sie können aber natürlich auch in einem Terminal mit parted arbeiten. Auf jeden Fall erhalten Sie keine Unterstützung durch das Installationsprogramm, das keinen Partitionseditor hat. Stattdessen zeigt es die mit GParted oder parted erzeugten Partitionen nur an. Sie können nun über kleine Dialoge entscheiden, wie Sie die Partitionen für die Installation nützen möchten.

Selbstredend habe ich mich für die zweite Variante entschieden. Mein Ziel war, auf der SSD Platz für weitere Linux-Installationen zu lassen. Das Problem besteht nun darin, dass Pop!_OS bei der Custom-Variante keine Verschlüsselungsoption anbietet. Vielmehr müssen Sie die Datenpartition mit crypt_setup selbst vorbereiten.

Ich habe daher in einem Terminal die notwendigen Vorbereitungsarbeiten selbst durchgeführt. Zuerst habe ich auf der SSD eine GPT-Partitionstabelle eingerichtet. (Vorsicht! Alle auf der SSD befindlichen Daten gehen dabei verloren.)

parted /dev/nvme0n1
>   mklabel gpt

Immer noch in parted habe ich eine EFI-Partition eingerichtet:

> mkpart EFI 1mib 1024mib
> set 1 hidden
> set 1 esp

Und schließlich die Datenpartition, wobei die letzten 250 GiB der SSD frei bleiben sollten:

> mkpart encryptedpop 1025mib -250gib
> exit

Die EFI-Partition benötigt ein VFAT-Dateisystem:

mkfs.vfat /dev/nvme0n1p1

Die Datenpartition wird mit crypt_setup verschlüsselt. (Dabei müssen Sie zweimal das gewünschte Passwort angeben.) Damit entsteht die neue Device-Datei /dev/mapper/cryptlvm:

cryptsetup luksFormat --type luks2 /dev/nvme0n1p2
ls /dev/mapper/cryptlvm 
    /dev/mapper/cryptlvm

Diese Device-Datei soll nun als Physical Volume für ein Volume Group für LVM dienen. In der Volume Group habe ich mit lvcreate ein Logical Volume eingerichtet.

pvcreate /dev/mapper/cryptlvm
vgcreate popvg /dev/mapper/cryptlvm
lvcreate -L 1500G popvg -n poproot

Auf eine Swap-Partition habe ich angesichts 32 GByte RAM verzichtet. Damit ist der Terminal-Voodoo beendet. Das Pop!_OS-Installationsprogramm erkennt sowohl die EFI-Partition als auch die verschlüsselte Partition und das darin enthaltene LVM-Setup.

Recovery-Partition: Wenn Sie möchten, dass Ihnen nach der Installation auf der Festplatte/SSD ein Recovery-System zur Verfügung steht, müssen Sie eine weitere 4 GByte große Partition vorsehen (VFAT, unverschlüsselt, außerhalb von LVM) und dieser im Installationsprogramm das Verzeichnis /recovery zuweisen. Das Recovery-System ist einfach ein Pop!_OS-Live-System.

Die weitere Installation erfolgt dann ohne weitere Rückfragen und innerhalb weniger Minuten. Nach dem Neustart muss noch ein Benutzer eingerichtet werden — das war’s.

Hinweis: Wenn Sie Pop!_OS in VirtualBox ausprobieren, passt sich die Auflösung der virtuellen Maschine nicht automatisch an die Fenstergröße an. Standardmäßig stehen u.U. nur 800×600 Pixel zur Verfügung. Abhilfe: Öffnen Sie in der virtuellen Maschine die Gnome-Einstellungen, öffnen Sie das Dialogblatt *Devices/Displays* und wählen Sie dort die gewünschte Auflösung aus.

Desktop

Nach dem ersten Login offenbart sich der Pop!_OS-Desktop als ziemlich gewöhnliches Gnome-System mit wenigen Modifikationen, die durch Shell Extensions, eigene Fonts und Themes realisiert sind.

NVIDIA-Unterstützung

Das Alleinstellungsmerkmal von Pop!_OS ist sicherlich die gute NVIDIA-Unterstützung out of the box, also ohne irgendwelche Konfigurationsarbeiten. Pop!_OS verfolgt dabei einen sehr pragmatischen Ansatz: Über zwei in das Gnome-Systemmenü eingebauten Kommandos kann zwischen der NVIDIA- und der Intel-GPU gewechselt werden. Jeder Wechsel erfordert einen Neustart. Das ist weniger bequem als unter Windows, aber es funktioniert (zumindest bei meinen Tests) zuverlässig.

Der GPU-Wechsel kann auch durch Kommandos initiiert werden, wobei auch diese Änderungen erst nach einem Reboot wirksam werden.

sudo system76-power graphics nvidia
sudo system76-power graphics intel

Hinter den Kulissen erzeugt system76-power eine neue Initrd-Datei. Anschließend werden die Dateien in /boot/efi/EFI/Pop_OS-xxx erneuert. Neugierig wie ich bin, habe ich die Initrd-Images ausgepackt (unmkinitramfs) und verglichen (diff -rq). Das Ergebnis: Die Initrd-Datei für NVIDIA enthält erwartungsgemäß die NVIDIA-Kernelmodule (nvidia-drm.ko, nvidia-modset.ko). Dafür enthält die Intel-Variante die folgende Datei:

# Datei /etc/modprobe.d/system76-power.conf 
blacklist nouveau
blacklist nvidia
blacklist nvidia-drm
blacklist nvidia-modeset
alias nouveau off
alias nvidia off
alias nvidia-drm off
alias nvidia-modeset off

Sowohl das system76-power als auch die dazugehörige Gnome-Erweiterung sind Open-Source-Projekte auf GitHub zu finden. Als Programmiersprache wurde Rust verwendet.

• https://github.com/pop-os/system76-power
• https://github.com/pop-os/gnome-shell-extension-system76-power

Als Grafiksystem kommt in Pop!_OS Xorg zum Einsatz. Diverse Wayland-Pakete sind zwar installiert, beim Login gibt es aber keine Möglichkeit, Wayland zu aktivieren. Das ist insofern konsequent, als die NVIDIA-Treiber ja inkompatibel zu Wayland sind).

Energieverwaltung

Mit system76-power und den dazugehörige Gnome Extension können Sie auch zwischen drei Nutzungsprofilen umschalten:

sudo system76-power profile battery 
sudo system76-power profile balanced
sudo system76-power profile performance

Ich habe keine schlüssige Dokumentation gefunden, was die obigen Kommandos exakt tun.

Sicher ist, dass das Battery-Profil die Hintergrundbeleuchtung des Bildschirms stark reduziert. (Die Helligkeit kann per Tastatur natürlich wieder angehoben werden.) Außerdem wird im Battery-Profil der Turbo-Modus der CPU deaktiviert:

cat /sys/devices/system/cpu/intel_pstate/no_turbo
  0

In den beiden anderen Modi lautet das Ergebnis jeweils 1, d.h. bei Bedarf taktet die CPU höher. Der CPU-Governor bleibt bei allen drei Profilen auf powersave:

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor | uniq
  powersave

Kurzum, der Unterschied zwischen Balanced und Performance ist unklar geblieben. Ich habe keine wesentliche Änderung des CPU-Verhaltens feststellen können. Benchmarks mit Geekbench ergaben jeweils (im Rahmen der üblichen Schwankungen) dieselben Ergebnisse.

Hintergrundinformationen:

https://github.com/pop-os/system76-power/wiki
https://wiki.archlinux.org/index.php/CPU_frequency_scaling

Paketverwaltung

Pop!_OS verwendet zusätzlich zu den Ubuntu-Paketquellen eine eigene Paketquelle:

http://ppa.launchpad.net/system76/pop/ubuntu

Mit meinem im Blogbeitrag Die LTS-Frage vorgestellten Script habe ich ermittelt, wie viele Pakete aus der Pop!_OS-eigenen Paketquelle stammen. Das Ergebnis ist verblüffend. Es sind über 100 Pakete!

accountsservice appstream-data-pop appstream-data-pop-icons
com.github.donadigo.eddy curl dmeventd dmsetup gdm3 geary
gir1.2-accountsservice-1.0 gir1.2-gdm-1.0:amd64
gir1.2-gnomedesktop-3.0:amd64 gnome-control-center
gnome-control-center-data gnome-control-center-faces
gnome-desktop3-data gnome-online-accounts
gnome-shell-extension-alt-tab-raise-first-window
gnome-shell-extension-always-show-workspaces
gnome-shell-extension-do-not-disturb
gnome-shell-extension-pop-battery-icon-fix
gnome-shell-extension-pop-shop-details
gnome-shell-extension-pop-suspend-button
gnome-shell-extension-system76-power hidpi-daemon initramfs-tools
initramfs-tools-bin initramfs-tools-core kernelstub
libaccountsservice0:amd64 libc-bin libc-dev-bin libc6:amd64 libc6:i386
libc6-dev:amd64 libcurl3-gnutls:amd64 libcurl4:amd64
libdevmapper-event1.02.1:amd64 libdevmapper1.02.1:amd64
libegl-mesa0:amd64 libegl1-mesa:amd64 libgbm1:amd64 libgdm1
libgl1-mesa-dri:amd64 libgl1-mesa-dri:i386 libglapi-mesa:amd64
libglapi-mesa:i386 libglx-mesa0:amd64 libglx-mesa0:i386
libgnome-desktop-3-17:amd64 libgoa-1.0-0b:amd64 libgoa-1.0-common
libgoa-backend-1.0-1:amd64 libgranite-common libgranite5:amd64
liblvm2app2.2:amd64 liblvm2cmd2.02:amd64 libnvidia-cfg1-418:amd64
libnvidia-common-418 libnvidia-compute-418:amd64
libnvidia-compute-418:i386 libnvidia-decode-418:amd64
libnvidia-decode-418:i386 libnvidia-encode-418:amd64
libnvidia-encode-418:i386 libnvidia-fbc1-418:amd64
libnvidia-fbc1-418:i386 libnvidia-gl-418:amd64 libnvidia-gl-418:i386
libnvidia-ifr1-418:amd64 libnvidia-ifr1-418:i386 libxatracker2:amd64
linux-generic linux-headers-4.18.0-16 linux-headers-4.18.0-16-generic
linux-headers-generic linux-image-4.18.0-16-generic
linux-image-generic linux-libc-dev:amd64
linux-modules-4.18.0-16-generic linux-modules-extra-4.18.0-16-generic
linux-signed-generic locales lvm2 mesa-va-drivers:amd64
mesa-vdpau-drivers:amd64 mesa-vulkan-drivers:amd64 multiarch-support
nvidia-compute-utils-418 nvidia-dkms-418 nvidia-driver-410
nvidia-driver-418 nvidia-kernel-common-418 nvidia-kernel-source-418
nvidia-utils-418 plymouth-theme-pop-basic pop-default-settings
pop-desktop pop-fonts pop-gnome-initial-setup pop-gnome-shell-theme
pop-gtk-theme pop-icon-theme pop-session pop-shop pop-theme
pop-wallpapers popsicle popsicle-gtk repoman system76-dkms
system76-io-dkms system76-power xserver-xorg-video-nvidia-418

Das macht, offen gesagt, ein wenig skeptisch: Ein modifizierter Kernel, diverse modifizierte Gnome-Pakete (inklusive des eigenen Paketmanagers pop-shop, der natürlich auf Gnome Software basiert und ebenso schlecht wie dieses Programm funktioniert) etc. Ist system76 wirklich in der Lage, all diese Pakete langfristig solide zu warten? Gerade mit modifizierten Gnome-Paketen ist selbst Canonical gescheitert und letztlich zurück in das Mainstream-Lager gewechselt.

Standardmäßig sind keine Snap-Pakete installiert. Selbst auf die Installation des Snap-Dämons hat system76 verzichtet. (Sie können das mit apt install snapd beheben, wenn Sie wirklich wollen.)

systemd-boot statt GRUB

Technisch gesehen die größte Überraschung ist, dass Pop!_OS auf Rechnern oder virtuellen Maschinen mit EFI nicht GRUB verwendet, sondern die systemd-Komponente systemd_boot. (Wenn Sie Pop!_OS hingegen in VirtualBox installieren, wo standardmäßig ein traditionelles BIOS aktiv ist, kommt GRUB zum Einsatz.)

Pop!_OS mit systemd-boot benötigt richtig viel Platz in der EFI-Partition. Auf meinem Notebook ohne Recovery-System sind es ca. 160 MByte:

cd /boot/efi/EFI/
du -h 
  155M  ./Pop_OS-e16cb407-87e1-4333-90b3-e3a05f8e80f7
  92K   ./systemd
  92K   ./BOOT
  155M  .

Bei der Clean Install-Variante beträgt der Platzbedarf sogar 200 MByte, weil ein weiteres Image zum Start des Recovery-Systems eingerichtet wird.

Noch ein paar Anmerkungen zur EFI-Partition: Hier speichern alle auf einem Rechner installierten Betriebssysteme (also Windows sowie alle Linux-Distributionen) ihren Bootloader. Üblicherweise beanspruchen die Dateien ca. 10 bis 20 MByte pro Betriebssystem. Bei Pop!_OS ist der Platzbedarf deswegen so viel größer, weil die Boot-Dateien auch den Kernel und das Initrd-Image mit einschließen. Das ist insofern praktisch, als keine unverschlüsselte Boot-Partition erforderlich ist. Alle für den Boot-Vorgang erforderlichen Dateien sind direkt in der EFI-Partition.

Auf Notebooks mit vorinstalliertem Windows ist die EFI-Partition zumeist 256 MByte groß. Mit Windows und Pop_OS! ist die EFI-Partition dann so gut wie voll. Eine Vergrößerung mit einem Partitions-Manager scheitert zumeist daran, dass sich oft unmittelbar hinter der EFI-Partition eine 16 MByte große reserved windows Partition befindet (siehe z.B. superuser.com).

Weil ich Probleme bei zukünftigen Linux-Installationen ausschließen wollte, habe ich während der Installation eine zweite EFI-Partition eingerichtet. Der EFI-Standard sieht dies vor (nochmals superuser.com), Windows ist aber anscheinend nicht immer glücklich damit. In meinem Fall gab es aber keine Probleme, Windows lässt sich weiter starten und liest die Boot-Dateien aus ’seiner‘ EFI-Partition, während Pop!_OS die zweite EFI-Partition nutzt.

Im Betrieb bleibt systemd-boot normalerweise komplett unsichtbar. Nur wenn Sie exakt zum richtigen Zeitpunkt die Leertaste drücken, erscheint ein Menü mit den zur Auswahl stehenden Systemen. Im Prinzip handelt es sich dabei um Pop!_OS mit dem aktuellen Kernel, Pop!_OS mit dem vorigen Kernel sowie gegebenenfalls ein Recovery-System.

Die Menüeinträge wählen Sie mit den Cursortasten aus. Bei Bedarf gelangen Sie mit [E] in einen Editor, in dem Sie die Kernelparameter verändern können. Weitere interaktive Funktionen gibt es nicht.

Die Konfiguration von systemd-boot erfolgt durch die Datei /boot/efi/loader/loader.conf. Dort können Sie unter anderem mit timeout n die Zeit in Sekunden einstellen, während der das systemd-boot-Menü angezeigt wird. (Die Defaulteinstellung lautet 0.) Standardmäßig enthält loader.conf nur die Zeile default osname, die auf eine der Menüdateien im loader-Verzeichnis verweist. Mehr Details zu den (spärlichen) Konfigurationsmöglichkeiten finden Sie im archlinuxwiki.

Ist systemd-boot nun besser oder schlechter als GRUB? Das ist schwer zu sagen. An sich gefällt der minimalistische Ansatz im Vergleich zu dem mit Funktionen überladenen GRUB. Sollten allerdings Boot-Probleme auftreten, ist eine allfällige Reparatur vermutlich schwieriger als bei GRUB — schon alleine deswegen, weil systemd-boot wenig verbreitet ist. Im Web sind nur wenige Anleitungen und eine dürftige offizielle Dokumentation und zu finden:

• https://wiki.archlinux.org/index.php/systemd-boot
• https://www.freedesktop.org/software/systemd/man/systemd-boot.html
• https://blog.system76.com/post/170539007243/distinst-updates-boot-sequence-optimization
• https://support.system76.com/articles/pop-recovery/

Recovery-System

Nach Wochen der Bastelei habe ich es endlich geschafft ein Snap-Paket für die AusweisApp2 zu bauen, welches auch mit dem Confinement funktioniert. Die einzige Einschränkung, die aktuell noch existiert, ist das man nach der Installation einmalig die benötigten Interfaces des Snap-Pakets „connecten“ muss. Danach funktioniert die Anwendung ohne weitere Einschränkungen:

sudo snap install ausweisapp2-ce

sudo snap connect ausweisapp2-ce:raw-usb :raw-usb
sudo snap connect ausweisapp2-ce:hardware-observe :hardware-observe
sudo snap connect ausweisapp2-ce:network-manager :network-manager
sudo snap connect ausweisapp2-ce:network-observe :network-observe

sudo systemctl restart snap.ausweisapp2-ce.pcscd.service

Letzterer Befehl ist notwendig, damit der Card-Daemon noch vor dem ersten Start der Anwendung die passenden Rechte besitzt.

Ich habe im Snap-Store einen Request zum Auto-Connecten gestellt. Falls dieser genehmigt wird, kann man die Anwendung auch ohne explizites „connecten“ installieren.

Update

Ich habe gestern (05.04.19) die Freigabe des Stores für das automatische „connecten“ der benötigten Interfaces erhalten. Es reicht jetzt also aus das Snap zu installieren. Es sind keine weiteren Schritte notwendig.

Am Wochenende fanden die 21. Chemnitzer Linux-Tage an der TU Chemnitz statt. Für mich war es nun schon der dritte Besuch nach 2015 und 2018.

Zu Vorträgen aus dem Vortragsprogramm kann ich nicht sehr viel sagen. Wie es sich bei mir mittlerweile Standard ist, bin ich mehr in Gesprächen mit den zahlreichen Freunden „verwickelt“ gewesen und weniger in Vorträgen gewesen. Am Samstag habe ich es immerhin geschafft den einzigen Vortrag für mich an diesem Tag zu besuchen: „Python asyncio in der Praxis“.

Am Sonntag habe ich es ebenfalls nur zu einem Talk geschafft. Allerdings war ich da der Speaker und musste (viel) reden. Wie auch bei der letzten OpenRheinRuhr erzählte ich über „How To Commit: Nachvollziehbare Git-Historien“. In diesem Vortrag erzählte ich über die Art und Weise wie Commits auszusehen haben sollten, damit diese auch im Nachhinein nachvollziehbar sind. Der Talk war auch als Diskussion ausgerichtet, weshalb einige Informationen und Wortmeldungen entsprechend nicht in den „Folien“ enthalten sind. Eine Aufzeichnung des Talks gab es hingegen und wird hoffentlich zeitnah auf der Webseite vom CLT veröffentlicht.

Die Folien finden sich auf meinem Speakerdeck Account oder eingebettet (via JavaScript) auch hier:

Das Thema des Talks wird für mich im Umgang mit Git immer wichtiger, sodass es in der kommenden zweiten Auflage meines Git Buches ein eigenständiges Kapitel gewidmet bekommen wird.

Unabhängig von meinem Talk lohnt sich ein Besuch der Chemnitzer Linux-Tage auch weiterhin. Eine schöne nette Community die sich da trifft. Für mich auch die Open-Source-Konferenz, die ich am besten mag. Und das liegt nicht nur an der guten Organisation… :)

Auch in diesem Jahr haben die Chemnitzer Linux Tage wieder in das zentrale Hörsaal- und Seminar-Gebäude der Technischen Universität Chemnitz eingeladen. Das Motto lautete diesmal „Natürlich intelligent“ und so wundert es nicht, dass sich eine Vielzahl von Vorträgen den Themen Künstliche Intelligenz und Maschinelles Lernen widmeten. Darüber hinaus gab es interessante Vorträge zu den Themen IoT, Container, Sicherheit, Einsteiger, Datacenter, usw. Alles in allem wurde wie im letzten Jahr ein vielseitiges Programm geboten.

Anreise am Freitag

Wie im vergangenen Jahr bin ich auch dieses Mal wieder mit dem Auto angereist, denn 4,5 Std. Fahrt sind mir doch lieber, als 6-7 Std. Reisezeit mit der Bahn (laut Fahrplan). So kam ich Freitag Abend rechtzeitig an, um das Social Event im Turmbrauhaus zu besuchen. Es war ein schöner Abend mit freundlichen Menschen bei interessanten Gesprächen und natürlich 1..n Hopfenkaltschalen.

Ich habe mich gefreut, bekannte Gesichter von ubuntuusers.de wieder zu sehen und neue Gesichter hinter einigen Blogs kennen zu lernen, die ich regelmäßig lese.

Auftakt am Samstag

Punkt 7.00 Uhr Frühstück im Hotel, 8.00 Uhr Einlass bei den Chemnitzer Linux Tagen und ab 9.00 Uhr öffnete die Ausstellerfläche und das Vortragsprogramm startete. Ich selbst lernte an diesem Tag etwas über Präsentationen mit XeLaTeX (Beamer), NVMe, NVMe over Fabrics und erfuhr die ein und andere Neuigkeit im persönlichen Gespräch mit alten und neuen Bekannten. Mein persönliches Zitat des Tages stammt von D. Menzel und lautet: „NVMe over Fabric ist wie iSCSI auf Steroiden.“ :-D

Ausklang am Sonntag

Auch der Sonntag begann früh mit dem Frühstück um 7.00 Uhr. Um 9.00 Uhr war bereits alles für die Abreise gepackt und die Chemnitzer Linux Tage öffneten ihre Halle für den zweiten Veranstaltungstag. Dieser startete für mich mit einigen Standbesuchen, um Informationen über mögliche Schulungsangebote und Tipps für den Einsatz von Ansible einzusammeln, bevor es dann um 10.00 Uhr in den ersten Vortrag, den Samba Status Report, ging.

Laut dem zuvor genannten Vortrag tritt SMB2 an, um NFS zu töten. Naja, ich persönlich glaube, Totgesagte leben länger.

Der Storage Track endete mit einem Vortrag von Kai Wagner, welcher über die Neuigkeiten im neuen Ceph Release Nautilus berichtete. In hohem Tempo führte Kai durch eine Folienschlacht, um keine coole Neuerung zu vergessen. Bei den vielen lang erwarteten Neuerung kann ich gut verstehen, dass Kai keine davon unterschlagen wollte. Dennoch hat Kai hier einen tollen und unterhaltsamen Talk gehalten. Danke hierfür.

Der letzte Vortag für mich an diesem Tage war Open Source und Medizin, welcher einen interessanten Einblick in die Forschung mit Medizindaten bot.

Im Anschluss wurden die Vorträge noch in kleinen Gruppen diskutiert, bevor ich mich verabschiedete, um mich auf den Heimweg zu machen.

Es war mal wieder ein schönes Wochenende und tolle Chemnitzer Linux Tage 2019. Bis zum nächsten Jahr.

Wurde in einem Wiki, das auf die Software MediaWiki setzt, das Passwort von einem Benutzer vergessen? Wenn das Wiki korrekt konfiguriert wurde und der Nutzer eine E-Mail-Adresse hinterlegt hat, kein Problem, da es hierfür die Funktion "Passwort vergessen" gibt, die unter dem Login-Formular abgerufen werden kann.

Ist ein solches Zurücksetzen allerdings nicht möglich, da z.B. der Mailtransport nicht aktiviert ist, muss das Passwort anderweitig erneuert werden. Wer sich schon auf den Weg in die Datenbank (Tabelle "user", Spalte "user_password", i.d.R. BLOB) macht, kann aufatmen, denn bei Zugriff auf die PHP-CLI schafft eines der MediaWiki-Wartungsscripte Abhilfe.

changePassword.php im maintenance-Verzeichnis ist für Passwort-Änderungen auf Kommandozeilenebene zuständig. Benötigt wird Zugriff auf das interne Verzeichnis, am besten per SSH. Dann per

cd /pfad/zur/installation/maintenance

in das maintenance-Verzeichnis der MW-Installation schalten und dort

php changePassword.php --user=Benutzername --password=NeuesPasswort

ausführen.

Die Optionsparameter müssen durch den zurückzusetzenden MW-Benutzernamen sowie das neu zu vergebende Passwort ersetzt werden. Das neue Passwort sollte grundlegende Passwortstandards (mehr als 8 Zeichen, etc.) erfüllen, damit eine Änderung möglich ist.

Tipp: alternativ bietet sich auch das gleiche Kommando mit vorangestelltem sudo an:

sudo -u www-data php changePassword.php --user=Benutzername --password=NeuesPasswort

Hier wird das Kommando unter dem Benutzer www-data, dem unter Debian für Apache2 üblichen Benutzer, ausgeführt. Bei anderen Paketen, Konfigurationen oder Distributionen muss dieser Wert natürlich enstprechend des dort eingestellten Webserver-Benutzers geändert werden.

KDE verfolgt bereits seit vielen Jahren mobile Pläne, herausgekommen ist dabei bisher nicht viel. Außer einem Framework namens Kirigami mit dem man klassische Desktopapplikationen mobil-tauglich machen möchte und damit das Benutzererlebnis auf dem Desktop ruiniert.

Wenn ich für irgendwas auf dem Linux Desktop Enthusiasmus entwickeln konnte, dann war dies immer KDE. Dank KDE bin ich erst richtig warm mit Linux geworden und habe dem Desktop über zwei große Versionssprünge die Treue gehalten. Zuletzt zunehmend frustriert (siehe auch die Serie ab: KDE Plasma 5 Teil I: Käfer und Schuldzuweisungen) aber ein Wechsel kam nie in Betracht. Seit einigen Jahren nutze ich nun auf dem Desktop macOS (siehe: Ein Apfel in der Antarktis - Teilwechsel auf macOS) und die virtuellen Maschinen laufen mit MATE.

KDE Plasma hat sich bei einigen Migrationsvorhaben allerdings immer wieder als sehr guter Desktop für Windows-Umsteiger erwiesen (siehe: openSUSE Leap im wartungsfreien Einsatz). Daher komme ich damit immer noch in Berührung. Nun habe ich mir mal den Entwicklungsstand von openSUSE Leap 15.1 angeguckt, da im Sommer einige Systeme darauf migriert werden sollen.

Vielleicht muss man erst mal Abstand zu einem Desktop gewinnen um den Entwicklern laut zuzurufen: Lasst das!

KDE Plasma ist nach wie vor ein toller Desktop und inzwischen auch hinreichend ressourcenschonend (siehe auch: Mythen V: KDE benötigt viele Ressourcen) und stabil. Das gilt sogar für notorische Problemkinder wie die Kontact-Suite, die hier im Produktiveinsatz keine nennenswerten Probleme macht. Von wirklichen Softwareperlen wie Dolphin mal ganz zu schweigen - der vielleicht beste Dateimanager unter allen Betriebssystemen und Desktopumgebungen, die ich je verwenden durfte.

Die Kirigami-basierten Anwendungen wie Discover und die neuen Systemeinstellungen sind jedoch furchtbar. Die Benutzerführung ist ganz offensichtlich an mobile Endgeräte angepasst, die Programme sind reaktionslangsam, es gibt Grafikfehler und bei Fenstervergrößerung/-verkleinerungen hängt alles.

Natürlich ist die Hardware nicht die Neueste. Ein Haswell i5 mit entsprechender Onboard-Grafikkarte liegt bei Linux aber im gesunden Mittelfeld, das hat die Ubuntu-Telemetriedatenerhebung ergeben.

Es ist schön, dass die Entwickler von Plasma Mobile am Ball bleiben. Die Zukunft liegt im mobilen Bereich und Linux darf sie nicht komplett verschlafen. Es gibt aber nach all den Jahren noch kein einziges mobiles Gerät auf dem Plasma Mobile läuft und keine Distribution einer lauffähigen Umgebung. Das wird sich vielleicht mit dem Librem 5 ändern, aber das kommt auch erst nächstes Jahr - frühestens!

Hört also auf die Desktopanwender in Geiselhaft für ein mobiles Unterfangen zu nehmen, das noch gar nicht existiert. Macht nicht das Desktoperlebnis für eure mobilen Träume kaputt. Sonst habt ihr am Ende nichts, keinen Desktop und kein mobiles System.

Bilder:

Einleitungs- und Beitragsbild von ElisaRiva via pixabay

Im zweiten Teil haben wir unserer Electron-App einen zum jeweiligen Betriebssystem passenden Look verpasst. Dabei haben wir je nach Plattform ein passendes Stylesheet verwendet, damit sich die Anwendung gut einpasst.

In diesem Teil werden wir nun das Menü der gtk3-demo-application nachbauen. Dazu werden wir als Erstes das App-Menü der Anwendung bauen. Dieses definieren wir beim Start der App. Als zweiten Schritt werden wir ein Kontext-Menü erstellen, dass zur Laufzeit der Anwendung komponiert wird. Damit unterscheidet es sich in der Art und Weise der Definition vom App-Menü.

Abschließend werden wir noch ein paar Optimierungen für Mac OS vornehmen. Das App-Menü auf einem Mac unterscheidet sich grundlegend von den Menüs unter Windows und Linux.

App-Menü

Das App-Menü erstellen wir in der Datei src/index.js. Dort wird es während des Starts der App geladen. Als Template für das Menü verwenden wir einen Javascript-Array, der Javascript-Objekte enthält. Die Javascript Objekte entsprechen einem Menüpunkt.

Das Menü-Template hat folgende Struktur:

[
  {
    label: 'NAME',
    submenu: [
      { role: 'NAME' },
      {
        label: 'NAME',
        click () { ... }
      }
    ]
  }
]

Jeder Menüpunkt kann wiederum eigene Untermenüs enthalten. Der sich so ergebende Baum stellt das App-Menü da.

Mit der Methode buildFromTemplate erstellen wir dann das Menü-Objekt.

Zusätzlich ergänzen wir src/index.js noch um eine Funktion showMessage, die uns als Dummy-Callback dient.

import { app, BrowserWindow, Menu, dialog } from 'electron';
...
  mainWindow = null;
  });

   const showMessage = message => dialog.showMessageBox({
    type: 'info',
    message: `You activated action: "${message}"`,
    buttons: ['Close'],
  });

   const menu = Menu.buildFromTemplate([
    {
      label: 'Preferences',
      submenu: [
        {
          label: 'Prefer Dark Theme',
          type: 'checkbox',
        },
        {
          label: 'Hide Titlebar when maximized',
          type: 'checkbox',
        },
        {
          label: 'Color',
          submenu: [
            {
              label: 'Red',
              type: 'radio',
              accelerator: 'CmdOrCtrl+R',
              click: () => showMessage('Red'),
            },
            {
              label: 'Green',
              type: 'radio',
              accelerator: 'CmdOrCtrl+G',
              click: () => showMessage('Green'),
            },
            {
              label: 'Blue',
              type: 'radio',
              accelerator: 'CmdOrCtrl+B',
              click: () => showMessage('Blue'),
            },
          ],
        },
        {
          label: 'Shape',
          submenu: [
            {
              label: 'Square',
              type: 'radio',
              accelerator: 'CmdOrCtrl+S',
              click: () => showMessage('Square'),
            },
            {
              label: 'Rectangle',
              type: 'radio',
              accelerator: 'CmdOrCtrl+R',
              click: () => showMessage('Rectangle'),
            },
            {
              label: 'Oval',
              type: 'radio',
              accelerator: 'CmdOrCtrl+O',
              click: () => showMessage('Oval'),
            },
          ],
        },
        {
          label: 'Bold',
          type: 'checkbox',
          accelerator: 'CmdOrCtrl+Shift+B',
          click: () => showMessage('Bold'),
        },
      ],
    },
    {
      label: 'Help',
      submenu: [
        {
          label: 'About',
          accelerator: 'CmdOrCtrl+A',
          click: () => dialog.showMessageBox({
            type: 'info',
            title: 'about',
            message: `GTK+ Code Demos
3.22.30
Running against GTK+ 3.22.30
Program to demonstrate GTK+ functions.
(C) 1997-2013 The GTK+ Team
This program comes with absolutely no warranty.
See the GNU Lesser General Public License, 
version 2.1 or later for details.`,
            buttons: ['Close'],
          }),
        },
      ],
    },
  ]);
  Menu.setApplicationMenu(menu);
...

Anschließend sollte das Menü zu sehen sein. Das Development-Menü wird nicht mehr angezeigt. Für ein größeres Projekt könnte es sinnvoll sein, ein Development-Menü zu erhalten, dass im Entwicklungsmodus angezeigt wird und bei Auslieferung ausgeschaltet wird.

Kontext-Menu

Die Demo-App besitzt auch ein Kontextmenü zur Textbearbeitung. Um dieses nachzubauen, gehen wir etwas anders vor. Wir erstellen es nicht mehr aus einem Template, sondern komponieren es zur Laufzeit.

Dementsprechend ergänzen wir unseren Code auch nicht mehr in der src/index.js, sondern in src/app.jsx.

Als Erstes definieren wir das Menü im Konstruktor unsere App-Komponente. Weil die Menu-Klasse nur im Hauptprozess zur Verfügung steht, müssen wir auf sie über das Remote-Objekt zugreifen.

Das Menü selbst ist sehr viel einfacher als das App-Menü gehalten. Wir fügen nur ein paar Standardfunktionen und einen Trenner in das Kontext-Menü ein. Wir machen dabei ausgiebig Gebrauch von der role-Option. Diese erlaubt uns, von Electron vordefinierte Standardmenüs zu verwenden.

    const menu = new remote.Menu();
    menu.append(new remote.MenuItem({ role: 'cut' }));
    menu.append(new remote.MenuItem({ role: 'copy' }));
    menu.append(new remote.MenuItem({ role: 'paste' }));
    menu.append(new remote.MenuItem({ role: 'delete' }));
    menu.append(new remote.MenuItem({ type: 'separator' }));
    menu.append(new remote.MenuItem({ role: 'selectall' }));
    this.menu = menu;
...
    this.onContextMenu = this.onContextMenu.bind(this);

Damit wir auf das Kontext-Menü zugreifen können, definieren wir einen onContextMenu-Handler für die Textarea. Dieser macht nichts anderes, als einfach das Kontextmenü zu öffnen und mit dem Hauptfenster zu verbinden.

  onContextMenu(event) {
    event.preventDefault();
    this.menu.popup({ window: remote.getCurrentWindow() });
  }
...
    <textarea id="TextField" onKeyDown={this.onInput} onContextMenu={this.onContextMenu} />

Jetzt kann man über der Textarea mit der rechten Maustaste ein Kontext-Menü aufrufen.

Mac-Menü

Das App-Menü unter Mac OS unterscheidet sich deutlich von den App-Menüs unter Windows und Linux.

In Mac OS gibt es 3 Standard Menüs, die jeder Anwendung bereitstellen sollte:

• window
• help
• services

Zu diesem Zweck stellt Electron unter Mac OS einige Standard-Menüs über Rollen bereit. Diese helfen beim Aufbau des Menüs.

Als Erstes speichern wir in src/index.js das Template für das App-Menü in einer eigenen Variablen.

Dann passen wir die Rolle unsere Hilfe-Menüs an.

Als Nächstes fügen wir die beiden anderen Unter-Menüs in unserem App-Menü ein, falls wir uns auf einem Mac befinden. Dazu verwenden wir Standard-JavaScript-Methoden, um unser Template-Array zu erweitern.

Wenn wir nun unsere Beispielanwendung auf einem Mac starten, wird das Menü im globalen Menü von Mac OS angezeigt.

Du findest den Source-Code für dieses Tutorial auf Github: https://github.com/rockiger/electron-react-example

Im letzten Teil werden wir uns um die Paketierung mit electron-forge kümmern.

Created with Dictandu

The post Cross-plattform Apps mit Electron und React Teil 3 appeared first on Rockiger.

Mozillas kostenloser und die Privatsphäre respektierender Filesharing-Dienst Firefox Send hat die Betaphase verlassen und erweitert nun offiziell das Produkt-Portfolio von Mozilla. Eine Android-App folgt in Kürze.

Bereits 2017 hat Mozilla Firefox Send im Rahmen von Test Pilot gestartet. Mit dem heutigen Tag verlässt Firefox Send die Beta-Phase und startet mit neuem Logo und neuer Webseite durch.

Dateien privat und sicher teilen mit Firefox Send

Firefox Send ist ein Dienst zum temporären Bereitstellen von Dateien. Die Nutzung von Firefox Send ist kostenlos und erfolgt durch eine Ende-zu-Ende-Verschlüsselung sicher. Durch die Festlegung einer Maximal-Dauer sowie einer Maximal-Anzahl an Downloads löschen sich die Dateien nach kurzer Zeit wieder von selbst vom Mozilla-Server.

Dauerhaft können Dateien nicht bei Firefox Send gelagert werden, denn es ist ein wesentlicher Teil des Konzeptes von Firefox Send, dass sich Nutzer nicht sorgen müssen, dass ihre Dateien für immer in der Cloud herumliegen. Optional kann außerdem auch noch ein Passwort festgelegt werden, ohne welches die Dateien nicht heruntergeladen werden können.

Firefox Send funktioniert mit jedem Browser, also nicht nur mit Firefox. Ein Firefox Account ist weder für das Hochladen noch für das Herunterladen von Dateien notwendig. Firefox Send ist also für jeden geeignet.

Ohne Anmeldung liegt das Limit bei 1 GB pro Datei. Wer sich mit seinem Firefox Account anmeldet, kann Dateien mit einer Größe von bis zu 2,5 GB hochladen.

Die Verwendung des Firefox Accounts hat außerdem den Vorteil, dass hochgeladene Dateien von jedem Gerät aus verwaltet werden können und nicht nur von dem Gerät, von welchem sie hochgeladen worden sind.

Außerdem ist ein höheres Limit als ein Download, nämlich bis zu 100 Downloads, sowie eine Maximal-Dauer von sieben Tagen nur mit Firefox Account möglich.

Zusätzlich soll schon bald, voraussichtlich sogar noch in dieser Woche, die erste Beta-Version einer Android-App von Firefox Send veröffentlicht werden.

Der Beitrag Mozillas Filesharing-Dienst Firefox Send startet offiziell erschien zuerst auf soeren-hentzschel.at.

Aktive Festplatten benötigen Energie, erzeugen Wärme, lassen den Lüfter laufen, verbrauchen dadurch noch mehr Energie und das meist völlig sinnlos, weil sie die meiste Zeit sowieso nicht benötigt werden. Daher sollte man Festplatten nach Möglichkeit bei Nichtgebrauch in den Standby schicken.

In heutigen NAS-Systemen arbeiten oft 2 und mehr große HDDs. Proprietäre Lösungen wie Synology oder QNAP haben daher längst Standby-Lösungen integriert. Ein normales Linux-Betriebssystem lässt die Festplatten allerdings 24/7 rotieren und erzeugt dadurch sinnlosen Energiebedarf. Nicht benötigte Festplatten sollten daher abgeschaltet werden

Voraussetzung ist dass das eigentliche System nicht auf einer der Festplatten liegt, da diese dann beständig wieder aufgeweckt werden würde und die Festplatte dadurch unnötigen Belastungen ausgesetzt wäre. Je nach Hardware kann man das eigentliche System z. B. auf eine kleine SSD installieren oder auch auf einen USB 3-Stick, der immer angeschlossen ist.

Grundsätzlich kann Linux mittels hdparm Festplatten bei Nicht-gebrauch in den Standby-Modus schicken. Hierzu ist lediglich eine Anpassung der Konfigurationsdatei /etc/hdparm.conf notwendig. Leider haben viele Distributoren die Situation verschlimmbessert indem sie die hdparm.conf ignorieren oder mit Skripten umgehen. Ubuntu und openSUSE sind hier unrühmliche Beispiele.

Eine einfache Möglichkeit das Problem zu beheben besteht in der Nutzung von TLP. Eigentlich handelt es sich dabei um eine Lösung zum Energiesparen auf Notebooks (ursprünglich sogar nur Thinkpads). Es lässt sich aber auch hervorragend auf Server- und Desktopsystemen nutzen.

Die Installation erfolgt bei vielen Distributionen direkt aus den Paketquellen. Bei openSUSE beispielsweise via:

# zypper in tlp

Anschließend muss die Konfiguration angepasst werden. Dies geschieht über die Datei /etc/default/tlp.

Folgender Abschnitt ist dabei von Interesse:

# Disk devices; separate multiple devices with spaces (default: sda).
# Devices can be specified by disk ID also (lookup with: tlp diskid).
DISK_DEVICES="sda"

# Disk advanced power management level: 1..254, 255 (max saving, min, off).
# Levels 1..127 may spin down the disk; 255 allowable on most drives.
# Separate values for multiple disks with spaces. Use the special value 'keep'
# to keep the hardware default for the particular disk.
DISK_APM_LEVEL_ON_AC="128"
DISK_APM_LEVEL_ON_BAT="128"

# Hard disk spin down timeout:
#   0:        spin down disabled
#   1..240:   timeouts from 5s to 20min (in units of 5s)
#   241..251: timeouts from 30min to 5.5 hours (in units of 30min)
# See 'man hdparm' for details.
# Separate values for multiple disks with spaces. Use the special value 'keep'
# to keep the hardware default for the particular disk.
DISK_SPINDOWN_TIMEOUT_ON_AC="120"
DISK_SPINDOWN_TIMEOUT_ON_BAT="120"

Unter DISK_DEVICES legt man fest welche Festplatten betroffen sein sollten. Im obigen Beispiel lediglich sda. Man könnte hier aber auch mehre Festplatten mit Leerzeichen getrennt angegeben.

Im zweiten Abschnitt legt man den APM-Level fest. Bei mehr als einer angegebenen Festplatte müssen die Werte nun ebenfalls für jede Platte angegeben und mit Leerzeichen getrennt werden. Viele Distributionen nehmen hier 254, was aber ein Abschalten verhindert. Hier muss man ein bisschen experimentieren, da das Verhalten je nach Festplatten-Modell unterschiedlich sein kann. Bei 128 (was oft auch für Notebooks verwendet wird) habe ich bei meinen WD Red Modellen gute Erfahrungen gemacht.

Der dritte Abschnitte steuert die Zeit, nach der die Festplatte ohne Zugriffe abgeschaltet werden. Die im Beispiel aufgeführten 120 bedeutet 10 Minuten. Der Wert ist ebenfalls für jede Platte anzugeben.

Abschließend aktiviert und startet man den Dienst:

# systemctl enable tlp

# systemctl start tlp

Mittels des folgenden Kommandos kann man überprüfen ob die Festplatte wie gewünscht in den Standby geht.

# hdparm -C /dev/sda

Folgende Ausgabe erscheint wenn die Festplatte korrekt in den Standby geht:

/dev/sda:
 drive state is:  standby

Kommt hingegen folgende Ausgabe ist die Festplatte aktiv:

/dev/sda:
 drive state is:  active/id

Bilder:

Einleitungs- und Beitragsbild von FreePhotosART via pixabay

Es muss nicht immer gleich der Red Hat Sattelite Server sein, um einen lokalen Spiegelserver für die Installation von RPM-Paketen bereitzustellen.

Auf GitHub habe ich im Repository „Poor man’s RHEL mirror“ eine kleine Sammlung von Bash-Skripten zusammengestellt, mit denen sich ein Spiegelserver für RHEL-Repositories aufbauen lässt. Mit diesem können RHEL-Repositories, für welche man eine gültige Subskription besitzt, auf einen Host im lokalen Netzwerk synchronisiert und deren Pakete anderen RHEL-Servern im LAN zur Verfügung gestellt werden.

Neben der reinen Spiegelung können mit den auf GitHub bereitgestellten Skripten weitere lokale Stage-Repositories eingerichtet werden, mit denen sich die Verfügbarkeit von Paketen für einzelne Stages steuern lässt. Zusätzlich bietet das Projekt Skripte, um eigene YUM-Repositories zu erstellen, um zum Beispiel eigene Pakete darüber bereitstellen zu können. Des Weiteren wurde die Möglichkeit berücksichtigt, die Red Hat Errata Informationen in die lokalen RHEL-Repositories zu integrieren, um die --advisory Option für YUM auch auf Systemen nutzen zu können, die über keine eigene Verbindung zum Internet verfügen.

Warum ist dieses Projekt nützlich?

• Es schont die eigene Internetverbindung, da Pakete nur einmal aus dem Internet heruntergeladen und anschließend im LAN zur Verfügung gestellt werden.
• Es unterstützt bei der Erstellung eines YUM-Repositories zur Bereitstellung von RPM-Paketen.
• Es unterstützt das Staging-Konzept, in dem es die Möglichkeit bietet, stage-spezifische Repositories bereitzustellen.
• Es implementiert die Red Hat Errata Informationen in die gespiegelten RHEL-Repos, so dass diese von angebundenen Servern genutzt werden können, die über keine eigene Internetverbindung verfügen.
• Es entstehen keine Zusatzkosten, da alle notwendigen Werkzeuge in den Repos einer RHEL-Standard-Subskription enthalten sind.

Wer kann dieses Projekt nutzen?

Das Projekt selbst steht unter der MIT-Lizenz und kann unter deren Bedingungen frei genutzt, modifiziert und weiter verteilt werden.

Für den Betrieb des Spiegelservers ist der Besitz einer gültigen RHEL-Subskription Voraussetzung. Denn es können nur jene Repos gespiegelt werden, für die eine gültige Subskription vorhanden ist. Auch alle an den Spiegelserver angeschlossenen Systeme müssen über eine entsprechende und gültige Subskription verfügen.

Bei Fragen zu Subskriptionen helfen die folgenden Seiten weiter:

• Red Hat subscription model FAQ
• Red Hat subscription service overview

Um mit diesem Projekt einen Spiegelserver aufsetzen und betreiben zu können, sind gewisse Kenntnisse erforderlich. Zu diesen zählen die Installation eine RHEL-Systems inkl. Registrierung, das Hinzufügen von Subskriptionen und die Installation von Paketen. Informationen hierzu bietet die Product Documentation for Red Hat Enterprise Linux 7.

Wie ist das GitHub-Repository zu diesem Projekt aufgebaut?

Das GitHub-Repository beinhaltet ein README, welches einen Überblick über das Projekt und eine Kurzbeschreibung der einzelnen Skripte in englischer Sprache beinhaltet. Im Master-Branch befindet sich die letzte stabile Version des Projekts. Weiterentwicklungen und Fehlerkorrekturen werden im Dev-Branch gepflegt und nach einer Testphase in den Master-Branch übernommen.

Sorgen, Nöte und Anträge sowie gefundene Fehler dürfen gern über die Issue-Funktion oder in den Kommentaren zu diesem Beitrag gemeldet werden.

An dieser Stelle folgt eine Beschreibung in deutscher Sprache, wie ein Spiegelserver mit diesem Projekt aufgebaut werden kann. Dabei handelt es sich um keine Schritt-für-Schritt-Anleitung und es werden grundlegende Kenntnisse über den Betrieb eines RHEL-Servers und die Installation sowie Konfiguration von Paketen vorausgesetzt.

Einrichtung eines Spiegelservers für arme Sysadmins

Um das Projekt nutzen zu können, benötigt man eine RHEL-Installation mit gültiger Subskription, auf welcher mindestens die folgenden Pakete installiert sein müssen:

• reposync und createrepo, um RHEL-Repos synchronisieren und eigene Repos erstellen zu können
• git zum Klonen des hier beschriebenen Projekts
• Die Gruppe Basic Web Server oder einen anderen Webserver eurer Wahl, um die gespiegelten Repos über HTTP im LAN bereitstellen zu können

Zu Beginn sind die Dateien aus dem oben genannten GitHub-Repository in einem Verzeichnis auf dem lokalen Host bereitzustellen. Anschließend ist das Projekt zu konfigurieren. Die dazu notwendigen Schritte werden in den folgenden Abschnitten erläutert.

CONFIG.SAMPLE

Hierbei handelt es sich um die Hauptkonfigurationsdatei. Diese ist in CONFIG umzubenennen bzw. zu kopieren und zu editieren. In dieser Datei werden die Variablen gesetzt, die von den verschiedenen Shell-Skripten verwendet werden. Darunter sind z.B. Angaben, welche Repos gespiegelt werden und wo die Dateien gespeichert werden sollen.

Die Datei ist mit Kommentaren versehen und sollte weitgehend selbsterklärend sein (was für alle weiteren Dateien gilt).

create_yum_repo.sh

Dieses Skript kann genutzt werden, um ein eigenes YUM-Repository zu erstellen, über welches RPM-Pakete bereitgestellt werden können. Der Name des zu erstellenden Repos kann dem Skript als Parameter übergeben werden.

do_reposync.sh

Dies ist das Herzstück des Projekts. Es kümmert sich um die Spiegelung der RHEL-Repos. Die notwendigen Parameter werden in der Datei CONFIG konfiguriert.

Das Skript lädt nur die aktuellen Pakete aus den Repos herunter, löscht aus den Upstream-Repos entfernte Pakete jedoch nicht automatisch auf dem lokalen Host. Dies ist meinen persönlichen Anforderungen geschuldet. Es ist nicht ausgeschlossen, dass ich diese Parameter in Zukunft ebenfalls konfigurierbar gestalte.

Einen Überblick über den Speicherbedarf ausgewählter RHEL-Repos findet ihr hier: How much disk space do I need for reposync?

Um die heruntergeladenen Pakete im LAN zur Verfügung zu stellen, muss das BASEDIR (siehe CONFIG) über einen Webserver zugreifbar gemacht werden.

refresh_repo.sh

Werden einem Repo neue RPM-Dateien hinzugefügt, muss die Metadaten-Datenbank aktualisiert werden, damit Klienten die neuen Pakete auch finden können. Um diese Aktualisierung kümmert sich eben dieses Skript.

rsync_repo.sh

Mit diesem Skript lassen sich Repos auf dem lokalen System synchronisieren. Dabei werden die Dateien jedoch nicht 1:1 kopiert, sondern Hardlinks erstellt. Dies spart bei der Verwendung mehrerer Repos für unterschiedliche Stages Speicherplatz.

Neben dem kompletten Sync eines Repos ist es auch möglich, dem Skript eine Datei zu übergeben, welche die Namen der Pakete enthält, welche in ein weiteres Repo „transportiert“ werden sollen.

Wrapper-Scripts

In meiner Umgebung arbeiten wir mit bis zu vier verschiedenen Stages (E, I, Q und P). Für jede dieser Stages wird ein eigenes Stage-Repo des Upstream rhel-7-server-rpms erzeugt. Um diese Stage-Repos zu aktualisieren, werden die folgenden Skripte verwendet:

• update_rhel-e-stage.sh
• update_rhel-i-stage.sh
• update_rhel-q-stage.sh
• update_rhel-p-stage.sh

Jede Stage wird mit den Paketen aus der vorhergehenden aktualisiert. So ruft z.B. update_rhel-e-stage.sh das Skript rsync_repo.sh, um die Pakete aus dem lokalen Spiegel des Upstreams rhel-7-server-rpms zu importieren. update_rhel-i-stage.sh verwendet dementsprechend die rhel-e-stage als Quelle usw.

Diese Konfiguration ist für meinen Anwendungsfall optimiert. Die Verwendung der Skripte ist optional. Der Spiegelserver funktioniert auch ohne diese Wrapper-Scripts.

update_mirror_packages_and_erratas.sh

Dieses Skript aktualisiert die Pakete in den Repos des lokalen Spiegelservers inkl. der Red Hat Errata Informationen. Letztere ermöglichen es, die Erratas (RHSA, RHBA und RHEA) auch Systemen verfügbar zu machen, welche über keine Verbindung zum Internet verfügen.

Das Skript ist in der Standardeinstellung auf meinen Anwendungsfall optimiert und aktualisiert am Ende alle vorhandenen RHEL-Stage-Repos. Wer diese Funktion nicht benötigt, kann sie durch Auskommentieren der Zeilen 45 und 46 im Skript deaktivieren.

Anschließend kann ein Cronjob erstellt werden, welcher das Skript ausführt, um den Spiegelserver regelmäßig gemäß der eigenen Anforderungen zu aktualisieren.

Die gespiegelten Repos verfügbar machen

Hat man die Repos seiner Wahl gespiegelt, ergibt sich je nach Konfiguration eine Verzeichnisstruktur ähnlich der folgenden.

$ tree -L 2
.
├──  rhel-7-test-mirror
│   ├── rhel-7-server-extras-rpms
│   ├── rhel-7-server-optional-rpms
│   ├── rhel-7-server-rpms
│   ├── rhel-7-server-supplementary-rpms
│   ├── rhel-e-stage
│   ├── rhel-e-stage.repo
│   ├── rhel-i-stage
│   ├── rhel-p-stage
│   ├── rhel-q-stage
│   └── rhel-server-rhscl-7-rpms

Das Verzeichnis rhel-7-test-mirror aus obigen Beispiel enthält die gespiegelten Repos als Unterverzeichnisse. Dieses Verzeichnis sollte über einen Webserver zugreifbar gemacht werden, um die Pakete den Clients im lokalen Netzwerk verfügbar zu machen.

Im obigen Listing ist eine Datei namens rhel-e-stage.repo zu sehen. Dabei handelt es sich um eine Repo-Datei, welche heruntergeladen und im Verzeichnis /etc/yum.repos.d/ platziert werden kann, um wie in diesem Beispiel das Repo rhel-e-stage zu aktivieren.

Aufbau einer Repo-Datei

Das folgende Listing zeigt die kommentierte Repo-Datei aus dem vorstehenden Abschnitt. Sie kann als Muster für weitere eigene Repo-Dateien dienen.

[rhel-e-stage] # Repo ID
baseurl = http://example.com/rhel-7-test-mirror/rhel-e-stage/
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
name = Repo for rhel-7-server-rpms (Test)

Fragen, Sorgen, Nöte und Anträge

Das Projekt und die enthaltene Software werden so wie sie sind unter der angegebenen Lizenz zur Verfügung gestellt.

Fragen, Sorgen, Nöte und Anträge können sowohl hier in den Kommentaren zum Artikel, als auch auf Github hinterlassen werden.

Ich hoffe, dass dieses Projekt euch (weiterhin) nützlich ist und freue mich über Rückmeldungen, wie es euch gefällt.