ubuntuusers.de

Von Linux gibt es drölfzig Distributionen. Das wird gerne kritisiert, weil dadurch massiv Ressourcen gebunden werden. Befürworter verteidigen immer die Vielfalt als Stärke von Linux. Das gilt aber auch nur wenn man die Vielfalt auch wirklich zulässt und nutzt.

Aktuell gibt es nur Pseudo-Vielfalt unter den Distributionen, denn im Grunde genommen sind sie sich alle sehr ähnlich. Es gibt Distributionen mit rollenden Veröffentlichungsmodellen und stabile Distributionen mit festgelegten Releasezyklen und Supportzeiträumen. Bei Letzteren muss man noch die kleine Gruppe der Distributionen mit LTS/Enterprise-Support separieren.

Alle Distributionen funktionieren sehr ähnlich. Meistens bieten sie alle verfügbaren Desktopumgebungen an, die zunehmend lieblos integriert werden, weil die hohe Schlagzahl bei zurückgehenden Ressourcen keine liebevolle Integration mehr zulässt. Die allermeisten Distributionen verwenden systemd, udev, PolKit, eine X11/Wayland-Kombination, kompilieren mit GCC usw. usf.

Es gibt nur ein paar wenige exotische Distributionen mit Grundlagen, die sich deutlich von allen anderen unterscheiden. Spontan fallen mir da vielleicht Gentoo, Void, Slackware und vielleicht Devuan ein. Gemessen an der Gesamtzahl fallen diese kaum ins Gewicht.

Wo ist der Unterschied zwischen Linux Mint und Ubuntu oder zwischen Ubuntu und Debian? Wo ist der Unterschied zwischen Mageia und Fedora, zwischen openSUSE und Mageia? Wo trennt sich Manjaro von Arch Linux und was sind die Vorteile gegenüber openSUSE Tumbleweed? Man muss schon ganz weit heran zoomen, um hier noch die große Vielfalt zu erkennen, die angeblich der Vorteil von Linux ist.

Wenn also Distributionen wie Fedora mit Silverblue an der Distribution der Zukunft bauen, openSUSE mit MicroOS experimentiert, Ubuntu demnächst mehr Snaps ausrollen und elementary OS ein kuratiertes Flatpak-Ökosystem aufbauen, ist das eine Chance. Eine Chance auf wirkliche Vielfalt.

Es wird schließlich noch genug Distributionen geben, die andere Wege einschlagen. Die an konventionellen Veröffentlichungen festhalten, Flatpaks oder Snaps nicht standardmäßig verteilen oder sogar komplett aussperren.

Meiner Meinung nach könnte das noch viel weiter gehen. Anstatt 6 Desktops stiefmütterlich zu unterstützen, sollte man sich auch hier lieber auf einige wenige konzentrieren und hier auch guten Support bieten. So wie Fedora dies mit GNOME macht oder KDE neon mit Plasma. Andere Distributionen können hier ja andere Entscheidungen treffen.

Wenn nicht mehr alle Distributionen alles bieten, muss vielleicht der ein oder andere seine Distribution wechseln. Das Ökosystem gewinnt aber insgesamt hinzu. An wirklicher Vielfalt, an Wahlmöglichkeiten und an Qualität.

Momentan ist die vermeintliche Vielfalt nur ein Argument jener, die jede Kritik am Distributionsdschungel wegwischen wollen. Kaum entsteht wirkliche Vielfalt, wie bei Canonicals Entscheidung, künftig stärker auf Snaps zu setzen, kommt ein lautes Wehklagen, ob des vermeintlichen Verrats am Linux-Einheitsbrei und der Drohung, dass man dann selbst woanders hin abwandern möchte (gerne versteckt als „dann werden viele User gehen“).

Super, dann geht doch. Das ist überhaupt nicht negativ gemeint, denn genau dafür hat Linux doch die Vielfalt. Es muss nicht jede Distribution zu jedem Anwender oder Anwendungsfall passen. Gefällt einem eine Distribution nicht, sucht man sich eine andere. Vielfalt bedeutet nicht, hundert austauschbare Distributionen zu haben.

Der Artikel Kommentar: Viele Distributionen nutzen nur bei wirklicher Vielfalt etwas erschien zuerst auf [Mer]Curius

Bei Etherpad handelt es sich um einen Editor für kollaboratives Schreiben, welcher selbst gehostet werden kann. Soll Etherpad unter Ubuntu gehostet werden, muss im ersten Schritt Node.js installiert werden:

apt install -y libssl-dev
curl -sL https://deb.nodesource.com/setup_14.x | bash -
apt install -y nodejs

Anschließend wird ein Nutzer für Etherpad angelegt und in diesen gewechselt werden und dort der Quellcode für Etherpad heruntergeladen und initial einmal gestartet und dann mittels Strg + C wieder beendet:

adduser --disabled-login --gecos "" etherpad
su - etherpad
git clone --branch master https://github.com/ether/etherpad-lite.git
cd etherpad-lite
npm install sqlite3
src/bin/run.sh

Nun werden einige Konfigurationen vorgenommen. Im Groben werden die Datenbank, die Authentifikation, Vorbereitungen für den Reverse Proxy, die Nutzer und die maximale Länge von einzufügendem Inhalt und das Log konfiguriert:

nano etherpad-lite/settings.json

Die Änderungen sind in ihrer Reihenfolge in der Konfigurationsdatei angegeben:

...

"dbType": "sqlite",
"dbSettings": {
  "filename": "var/sqlite.db"
},

...

"requireAuthentication": true,

...

"trustProxy": true,

...

"users": {
"admin": {
  // 1) "password" can be replaced with "hash" if you install ep_hash_auth
  // 2) please note that if password is null, the user will not be created
  "password": "example",
  "is_admin": true
},
"user": {
  // 1) "password" can be replaced with "hash" if you install ep_hash_auth
  // 2) please note that if password is null, the user will not be created
  "password": "example",
  "is_admin": false
}
},

...

"socketIo": {
/*
 * Maximum permitted client message size (in bytes). All messages from
 * clients that are larger than this will be rejected. Large values make it
 * possible to paste large amounts of text, and plugins may require a larger
 * value to work properly, but increasing the value increases susceptibility
 * to denial of service attacks (malicious clients can exhaust memory).
 */
"maxHttpBufferSize": 1048576
},

...

"logconfig" :
{ "appenders": [
    { "type": "console"
    //, "category": "access"// only logs pad access
    }

  , { "type": "file"
  , "filename": "etherpad.log"
  , "maxLogSize": 1024000
  , "backups": 3 // how many log files there're gonna be at max
    }

...

Anschließend wird der Kontext des Nutzers etherpad verlassen und eine neue Service-Unit für systemd angelegt:

exit
nano /etc/systemd/system/etherpad.service

Diese wird mit folgendem Inhalt befüllt:

[Unit]
Description=Etherpad
After=syslog.target
After=network.target

[Service]
Type=simple
User=etherpad
Group=etherpad
Environment="NODE_ENV=production"
ExecStart=/home/etherpad/etherpad-lite/src/bin/run.sh
Restart=always

[Install]
WantedBy=multi-user.target

Nachdem die Datei angelegt wurde, kann der Service aktiviert und gestartet werden:

systemctl enable etherpad
systemctl start etherpad

Lokal ist der Service nun per HTTP unter dem Port 9001 erreichbar. Damit der Service auch von außen erreichbar ist, kann Nginx als Reverse Proxy konfiguriert werden. Dazu muss die entsprechende Konfiguration hinterlegt werden:

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;

    server_name example.org;

    client_max_body_size 512m;

    location / {

        # Set proxy headers
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # These are important to support WebSockets
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";

        # Make sure to set your Etherpad port number
        proxy_pass http://localhost:9001;
    }
}

Damit steht Etherpad auch von außen unter der entsprechenden Domain zur Verfügung und kann benutzt werden.

Mi, 22. September 2021, Ralf Hersel

Die LTS-Releases von Ubuntu erhalten 5 Jahre Update-Unterstützung. Firmenkunden, die die Extended Security Maintenance (ESM) Variante in Anspruch nehmen, erhalten nun für die alten Releases Ubuntu 14.04 und 16.04 zehn Jahre lang Sicherheitsupdates. Die Grafik zeigt, was das für die letzten vier LTS-Versionen bedeutet:

Die Unterstützung über 5 Jahre ist kostenlos für alle LTS-Versionen von Ubuntu. Die Preise für die erweiterte Unterstützung gestalten sich so:

Quelle: https://ubuntu.com//blog/ubuntu-14-04-and-16-04-lifecycle-extended-to-ten-years

Ubuntu stellt demnächst Firefox auf Snap um. In der Community kochen mal wieder die Gemüter hoch. Anstelle mich immer zu wiederholen, fasse ich hier mal alle relevanten Punkte zusammen. Das Ziel ist ein möglichst sachlicher Überblick

Es gibt unterschiedliche Arten wie Betriebssysteme Software organisieren. Windows und macOS haben lange auf separate Installationsroutinen für einzelne Programme gesetzt, die auf ein Betriebssystem mit eigener Updateroutine installiert werden. Heute drängen beide mehr oder minder erfolgreich auf die Adaption des App Store-Prinzips auch für den Desktop.

Die verschiedenen Linux-Distributionen haben stattdessen aus unterschiedlichen Gründen eine zentrale Paketverwaltung für die Installation und Aktualisierung des gesamten Systems, letztlich vom Kernel bis zum Taschenrechner, entwickelt. Dabei gab und gibt es unterschiedliche Spielarten, aber das System funktioniert bei fast allen Distributionen gleich.

Das hat nichts mit Open Source vs. proprietäre Software zu tun, was man schon daran sehen kann, dass die verschiedenen BSD-Varianten noch mal ganz andere Modelle aufgezogen haben.

Ganz zentral ist, dass es kein entweder/oder gibt. Die Entwickler von Flatpak respektive Snap haben nie die Absicht geäußert, klassische Paketverwaltungen gänzlich zu ersetzen und selbst wenn eine Distribution komplett bei klassischen Paketverwaltungen bleiben möchte, kommt man vermutlich zukünftig zumindest bei manchen proprietären Programmen nicht um die Nutzung von Flatpak bzw. Snap umhin.

Die Sinnhaftigkeit von zwei neuen Lösungen, also Flatpak und Snap, kann man infrage stellen. Es wird hier keine Analyse der Unterschiede der einzelnen beiden Lösungen geben und auch keine Prognose abgegeben, ob beide dauerhaft überleben, oder nur eines von beiden sich durchsetzt. Neben Flatpak und Snap gibt es mit AppImages und Container-Ansätzen weitere Lösungen, die hier nicht berücksichtigt werden.

Paketverwaltung

Kennzeichen der klassischen Paketverwaltung:

• Die Paketverwaltung dient zur zentralen Installation und Aktualisierung aller Bestandteile des gesamten Systems.
• Der Bezug erfolgt heute i. d. R. über zentrale Repositorien und erfordert eine Internetverbindung.
• Programme werden nach Möglichkeit in ihre Bestandteile zerlegt und z. B. Bibliotheken oder Sprachdateien separiert. Eine Abhängigkeitsauflösung erfolgt durch die Paketverwaltung und sorgt dafür, dass alle notwendigen Bestandteile installiert werden.
• Rechte werden über Benutzer- und Gruppenrechte, sowie Dateisystemberechtigungen gesteuert.

Vorteile der klassischen Paketverwaltung:

• Programme benötigen keine separaten Updateroutinen.
• Eine Distribution ist eine aufeinander abgestimmte Gesamtkomposition, in der idealerweise alles perfekt harmoniert und getestet ist.
• Die Distributoren können Programme zielgenau patchen und gezielt bestimmte Versionen nutzen.
• Durch die Aufspaltung der Programme und Abhängigkeiten können einzelne Bibliotheken von vielen Programmen genutzt werden. Idealerweise ist keine Bibliothek doppelt installiert.

Nachteile der klassischen Paketverwaltung:

• Das System führt zu einem Duopol aus Rolling Release Distributionen (alles vom Kernel bis zum Taschenrechner wird fortlaufend aktualisiert) und stabilen Distributionen (nur Sicherheitsupdates und Fehlerbehebungen für alles vom Kernel bis zum Taschenrechner).
• Je älter die Basis, desto schwieriger bis ganz unmöglich ist die Aktualisierung einzelner Bestandteile, weil Abhängigkeiten auf gemeinsam genutzte Bestandteile irgendwann nicht mehr erfüllt werden können.
• Aufgrund der komplexen Abhängigkeitsauflösung ist es nicht komfortabel Pakete herunterladen und offline zu installieren.
• Jedes Programm muss für jede Distribution neu paketiert werden. Das bedeutet angesichts der aktuellen Anzahl an Distributionen, dass die Arbeit bis zu 100 Mal wiederholt wird.
• Entwickler müssen hoffen, dass ihr Programm von jeder wichtigen Distribution paketiert und damit den Endanwendern zur Verfügung gestellt wird.
• Entwickler haben Schwierigkeiten zu testen und Fehler zu reproduzieren, weil sie keinen Einfluss darauf haben, welche Bibliotheken und welchen Versionen vorliegen.
• Paketverwaltung sind sehr mächtige Systeme und lassen sich nur ungenügend mit einfachen App-Store-ähnlichen Oberflächen administrieren.

Neue Formate Flatpak / Snap

Kennzeichen der neuen Formate Flatpak / Snap:

• Dient konzeptionell nur dazu Programme und nicht das gesamte System zu verwalten.
• Nur Snap: Der Bezug erfolgt über ein zentrales Repositorium unter der Kontrolle von Canonical.
• Nur Flatpak: Distributoren können eigene Repositorien betreiben, faktisch gibt es mit Flathub eine übergreifende zentrale Bezugsplattform.
• Rechteverwaltung mittels einer Sandbox-Lösung mit spezielle Zugriffsrechten (AppArmor bei Snap; Portals bei Flatpak)
• Programme im Flatpak / Snap-Format bringen viele Bibliotheken bereits mit, nur wenige gemeinsam genutzte Bestandteile und keine ausdifferenzierte Abhängigkeitsverwaltung.

Vorteile der neuen Formate Flatpak / Snap:

• Flatpaks / Snaps können unabhängig von der Betriebssystem-Basis aktualisiert werden.
• Ein Snap oder Flatpak muss nur 1 Mal erstellt werden und kann anschließend unter allen Distributionen genutzt werden.
• Flatpaks / Snaps bringen die Bibliotheken in exakt den Versionen mit, für die sie getestet wurden.
• Flatpaks / Snaps ermöglichen es unterschiedliche Versionen von Programmen gleichzeitig zu installieren.
• Es gibt eine moderne Zugriffssteuerung, um Programmen ggf. den Zugriff auf das Dateisystem, die Kamera, das Mikrofont etc. pp. zu beschränken.
• Flatpak / Snap ermöglicht in Kombination mit anderen Lösungen gänzlich neue Typen von Distributionen wie z. B. Fedora Silverblue oder openSUSE MicroOS.

Nachteile der neuen Formate Flatpak / Snap:

• Bei Sicherheitsupdates für einzelne Bibliotheken müssen alle Flatpaks / Snaps aktualisiert werden, die diese enthalten. Es besteht das Risiko, dass dies nicht konsequent erfolgt.
• Die Verantwortung für die Prüfung der eingereichten Flatpaks / Snaps liegt bei Flathub respektive Snapcraft.io. Es bestehen Zweifel an der Qualität dieser Prüfung.
• Ein höherer Speicherplatzverbrauch, da letztlich dieselbe Bibliothek (ggf. in unterschiedlichen Versionen) mehrfach installiert wird. Das System ist weniger effizient in dieser Richtung.
• Kinderkrankheiten: Beide Formate sind immer noch nicht ausgereift. Es gab und gibt verschiedentlich Probleme mit Performance und der Steuerung der neuen Zugriffsrechte.

Der Artikel Flatpak / Snap vs. Paketverwaltung – Alles was dazu gesagt werden muss erschien zuerst auf [Mer]Curius

Die MZLA Technologies Corporation hat mit Thunderbird 91.1.1 ein Update für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 91.1.1

Thunderbird 91.1.1 ist ein Fehlerbehebungs-Update außer der Reihe, welches noch einmal eine ganze Reihe von Fehlern der Versionsreihe 91 behebt, ehe ab dieser Woche die Updates von Thunderbird 78 auf Thunderbird 91 aktiviert werden – zunächst nur für Nutzer in den USA. Eine Übersicht über die in Thunderbird 91.1.1 behobenen Fehler gibt es in den Release Notes (engl.).

Der Beitrag Thunderbird 91.1.1 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

In verwende seit einiger Zeit elementary OS im Consumer-Einsatz. Die Erfahrungen sind ziemlich positiv. Nun teste ich den weitestgehenden Umstieg auf Flatpaks.

In meinem Umfeld sind in den letzten Jahren einige Leute auf Linux umgestiegen. Ich empfehle das nicht aktiv, aber wenn der Wunsch von außen an mich herangetragen wird und eine Prüfung der Bedarfe Linux als mögliche Alternative ergibt, helfe ich gerne beim Umstieg. Ehrlicherweise allerdings auch langfristig als Ansprechpartner für Administration und Probleme. Das ist nur noch privat und semi-privat für ein KMU. Beruflich geht es für mich schon seit einiger Zeit in eine andere Richtung und weg von IT-„Management“.

Vor einiger Zeit habe ich damit begonnen, für diese Zwecke elementary OS auszutesten. Momentan betreue ich dadurch leider eine ziemlich krude Mischung aus Kubuntus und Systemen mit Pantheon Shell. Elementary OS 5 hatte leider einige nervige Bugs, weshalb ich längere Zeit auf Fedora setzte.

Die Pantheon Shell und die zugehörigen Programme plus Ergänzungen aus dem GNOME Ökosystem sind meiner Meinung nach ideal für Anwender, die keine Lust haben sich groß mit dem System zu befassen. Die Funktionsweise ist intuitiv und die Programme nicht überfrachtet mit Optionen. Die Anwender sind damit ziemlich zufrieden und ich bekomme sehr selten Probleme mit. Die Kubuntus machen mir da viel mehr Scherereien, nicht wegen Fehlern, sondern weil die Anwender es immer wieder hinbekommen, Plasma zu verunstalten und mit der Reorganisation der Elemente dann überfordert sind, weil die KDE-UX nicht intuitiv ist.

Die Integration von Pantheon in Fedora ist aber nur mittelmäßig und hat hier und da immer wieder für Probleme gesorgt. Trotz der Schwächen von elementary OS 6 habe ich daher angefangen, die Systeme sukzessive umzustellen.

Die elementary-Entwickler haben den Wechsel auf ein Flatpak-basiertes System eingeleitet. Das neue Appcenter kann zwar Aktualisierungen für APT durchführen, aber bietet Installationen von neuen Programmen nur über das Flatpak-Repo an. Ich stehe den neuen Formaten grundsätzlich offen gegenüber, obwohl ich persönlich bei meinem eigenen System noch eine klassische RR-Paketverwaltungssystem fahre.

Das Flatpak-Repo von elementary OS ist noch recht schmal bestückt, aber man kann Flathub unproblematisch systemweit einrichten und danach die dort enthaltenen Programme via Appcenter (oder Terminal) installieren.

Das habe ich auf einem „Testsystem“ jetzt mal konsequent verfolgt. Die klassische Paketverwaltung organisiert nun wirklich nur noch das Basissystem und die Desktopoberfläche. Alle Programme kommen konsequent aus dem elementary Flatpak-Repo oder von Flathub. Das ist der übliche Consumer-Mischmasch aus Firefox, Evolution, LibreOffice, Spotify, Anydesk usw. usf.

Der Vorteil ist ziemlich offensichtlich. Die Version von Kernel, X11, Mesa oder glibc ist hier völlig egal, die Hardware wird schon seit Kernel 5.4 perfekt unterstützt. Das Basissystem kommt nun direkt aus Ubuntu main plus die separat von elementary gepflegten Bestandteile. Das trägt notfalls bis ins Jahr 2025. Hier gibt es keine Überraschungen oder Updates, die Administration erforderlich machen. Durch den konsequenten Einsatz von Flatpaks entgeht man aber den ungepflegten Paketen in universe und bekommt hier immer die aktuelle stabile Version ausgeliefert.

Die Installation und die Updates laufen ziemlich problemlos und durch die Ähnlichkeit zu den mobilen Appstores ist das Verfahren auch sehr niedrigschwellig und bedurfte keiner weiteren Erklärung.

Ich bin gespannt wie sich das System so im Alltagsbetrieb schlägt, ob Probleme auftreten und wenn ja welche.

Der Artikel Experiment: elementary OS 6 mit Flatpaks erschien zuerst auf [Mer]Curius

In diesem Beitrag beschreibe ich exemplarisch, wie ein In-Place-Upgrade von RHEL 7 auf RHEL 8 durchgeführt werden kann. Dabei beschreibe ich zuerst, was ein In-Place-Upgrade ist und in welchen Fällen es sinnvoll sein kann, bevor ich im Hauptteil anhand einer Test-VM die Durchführung demonstriere.

Was ist ein In-Place-Upgrade?

Als In-Place-Upgrade wird der Vorgang bezeichnet, bei dem ein Betriebssystem auf ein neues Major-Release aktualisiert wird, ohne das System dabei neuinstallieren zu müssen. Statt dessen werden alle zum Betriebssystem gehörenden Dateien gegen die entsprechende Version des neuen Release ausgetauscht.

Nutzer von Debian und Ubuntu kennen dieses Verfahren unter dem Begriff Distributions-Upgrade.

• https://wiki.ubuntuusers.de/Upgrade/
• https://www.debian.org/releases/bullseye/i386/release-notes/ch-upgrading.de.html

In-Place-Upgrade vs. Neuinstallation

Grundsätzlich bevorzuge ich die Neuinstallation eines Systems. Da man sich üblicherweise mit Backups und Deployment-Skripten darauf vorbereitet hat, einen Dienst bzw. eine Anwendung nach einem Verlust des laufenden Systems wiederherstellen zu können, kann man sich dies auch zu Nutze machen und den Dienst bzw. die Anwendung auf einem frisch installierten System wiederherzustellen. Auf diese Weise werden keine Altlasten über mehrere Betriebssystemversionen mitgeschleppt.

Gleichzeitig kann man die Downtime verkürzen, indem das neue System parallel zum alten aufgebaut wird und man nach dem Abschluss aller Arbeiten und Tests umschaltet. Das Altsystem kann im Nachgang in Ruhe abgebaut werden.

Es gibt jedoch auch Gründe, die für ein In-Place-Upgrade sprechen. Verfügt man nur über einen einzigen Host und kann kein Parallelsystem aufbauen, kann ein In-Place-Upgrade die Lösung sein.

Evtl. verfügt man selbst zwar über ausreichend Berechtigungen, um das vorhandene System zu aktualisieren, für die Provisionierung neuer Systeme ist man jedoch auf die Unterstützung weiterer Stellen angewiesen. Die Abhängigkeitskette lässt sich hier zum Teil deutlich reduzieren.

Dabei muss stets bedacht werden, dass bei einem In-Place-Upgrade auch ein katastrophaler Fehler eintreten kann, welcher zum Verlust des Systems führt. Es ist daher dringend angeraten, eine Datensicherung zu haben, aus welcher das System wiederhergestellt werden kann. Besitzt man ein Backup, auf das man sich verlassen kann, kann es auch schon losgehen.

Das Upgrade von RHEL 7 auf RHEL 8

Laut Kapitel 1 der unter [0] verlinkten Dokumentation stellt das In-Place-Upgrade den von Red Hat unterstützten und empfohlenen Weg dar, um auf das nächste Major-Release zu aktualisieren. Dabei kann man stets nur von der letzten Verfügbaren RHEL 7 Version auf das jeweils letzte gerade RHEL 8 Release (z.B. 8.4) aktualisieren. Details hierzu können im Artikel unter [1] nachgelesen werden.

Die folgenden Abschnitte können die Dokumentation unter [0] nicht ersetzen. Sie sollen lediglich einen kompakten Überblick über den Prozess geben.

Limitierungen

Zum Zeitpunkt der Artikelerstellung , kann das In-Place-Upgrade nicht auf Systemen mit verschlüsselten Dateisystemen durchgeführt werden.

Netzwerkspeicher, wie z.B. iSCSI oder NAS, werden nicht unterstützt und müssen während des Upgrades ausgehängt werden. Die dazugehörigen Dienste, wie z.B. autofs müssen vorübergehend deaktiviert werden.

Weitere bekannte Probleme sind Kapitel 8 in [0] zu entnehmen.

Vorbereitung

Bevor man mit dem Upgrade beginnen kann, sind folgende Voraussetzungen zu schaffen:

• Das System erfüllt die minimalen Systemvoraussetzungen für RHEL 8 (siehe [2]).
• Zugriff auf Repos mit aktuellen Paketen für RHEL 7.9 und RHEL 8.4.
• Korrekte Registrierung des Systems am Red Hat Content Delivery Network (CDN) oder den Red Hat Satellite Server mittels Red Hat Subscription Manager (RHSM).

Wichtig: Ich empfehle ausdrücklich, vor Beginn der Arbeiten ein aktuelles Backup bzw. einen Snapshot zu erstellen, um auf den Ausgangszustand vor der Upgrade-Prozedur zurückkehren zu können.

Kapitel 2 in [0] bietet eine ausführliche Schritt-für-Schritt-Anleitung zur Vorbereitung des Upgrades. Der folgende Codeblock bietet eine kompakte Übersicht der einzelnen Schritte. Als Zielsystem dient eine aktuelle RHEL 7.9 Minimal-Installation.

[tronde@rhel7-t1 ~]$ # Überprüfung, ob eine RHEL-Subskription abonniert wurde
[tronde@rhel7-t1 ~]$ sudo subscription-manager list --installed
[sudo] password for tronde: 
+-------------------------------------------+
    Installed Product Status
+-------------------------------------------+
Product Name:   Red Hat Enterprise Linux Server
Product ID:     69
Version:        7.9
Arch:           x86_64
Status:         Subscribed
Status Details: 
Starts:         06.10.2020
Ends:           06.10.2021

[tronde@rhel7-t1 ~]$ # Aktivierung des RHEL 7 Basis- und Extras-Repo
[tronde@rhel7-t1 ~]$ sudo subscription-manager repos --enable rhel-7-server-rpms
Repository 'rhel-7-server-rpms' is enabled for this system.
[tronde@rhel7-t1 ~]$ sudo subscription-manager repos --enable rhel-7-server-extras-rpms
Repository 'rhel-7-server-extras-rpms' is enabled for this system.

[tronde@rhel7-t1 ~]$ # Ist locale auf en_US.UTF-8 gesetzt?
[tronde@rhel7-t1 ~]$ cat /etc/locale.conf
LANG="en_US.UTF-8"

[tronde@rhel7-t1 ~]$ sudo yum install leapp leapp-repository
# Ausgabe gekürtzt
Transaction Summary
================================================================================
Install  2 Packages (+24 Dependent packages)

Total download size: 5.3 M
Installed size: 19 M
Is this ok [y/d/N]: y
# Ausgabe gekürtzt

Pre-Upgrade-Bericht erstellen

Bevor das eigentliche Upgrade durchgeführt wird, führe ich auf meinem Testsystem das Kommando leapp preupgrade aus. Dieses sammelt Informationen über das System, um die Upgradefähigkeit zu bewerten und erstellt einen detaillierten Bericht, welcher im Pfad /var/log/leapp/leapp-report.txt abgelegt wird.

[tronde@rhel7-t1 ~]$ sudo leapp preupgrade
# Ausgabe gekürzt
============================================================
                           ERRORS                           
============================================================

2021-08-31 06:33:26.035495 [ERROR] Actor: repository_mapping
Message: Data file /etc/leapp/files/repomap.csv is invalid or could not be retrieved.
Summary:
    Details: Could not fetch repomap.csv from https://cert.cloud.redhat.com/api/pes/repomap.csv (unreachable address).
    Hint: Read documentation at: https://access.redhat.com/articles/3664871 for more information about how to retrieve the file.
2021-08-31 06:35:22.415297 [ERROR] Actor: restricted_pcis_scanner
Message: Data file /etc/leapp/files/unsupported_driver_names.json is invalid or could not be retrieved.
Summary:
    Details: Could not fetch unsupported_driver_names.json from https://cert.cloud.redhat.com/api/pes/unsupported_driver_names.json (unreachable address).
    Hint: Read documentation at: https://access.redhat.com/articles/3664871 for more information about how to retrieve the file.
2021-08-31 06:35:47.800140 [ERROR] Actor: pes_events_scanner
Message: Data file /etc/leapp/files/pes-events.json is invalid or could not be retrieved.
Summary:
    Details: Could not fetch pes-events.json from https://cert.cloud.redhat.com/api/pes/pes-events.json (unreachable address).
    Hint: Read documentation at: https://access.redhat.com/articles/3664871 for more information about how to retrieve the file.

============================================================
                       END OF ERRORS                        
============================================================


Debug output written to /var/log/leapp/leapp-preupgrade.log

============================================================
                           REPORT                           
============================================================

A report has been generated at /var/log/leapp/leapp-report.json
A report has been generated at /var/log/leapp/leapp-report.txt

============================================================
                       END OF REPORT                        
============================================================

Answerfile has been generated at /var/log/leapp/answerfile
[tronde@rhel7-t1 ~]$

Dem obigen Codeblock ist zu entnehmen, dass der Pre-Upgrade-Check Fehler festgestellt hat, die behoben werden müssen, bevor ein In-Place-Upgrade durchgeführt werden kann. Dankenswerter Weise ist sowohl in der Ausgabe auf STDOUT als auch in /var/log/leapp/leapp-report.txt der Knowledge-Base-Artikel [3] verlinkt, welcher die Lösung parat hält.

Ist dieser Fehler behoben, lässt man leapp preupgrade ein weiteres Mal laufen und prüft die Ausgabe erneut. Auf meinem Testsystem erhalte ich nun folgende Ausgabe:

[root@rhel7-t1 ~]# leapp preupgrade
# Ausgabe gekürzt
============================================================
                     UPGRADE INHIBITED                      
============================================================

Upgrade has been inhibited due to the following problems:
    1. Inhibitor: Missing required answers in the answer file
Consult the pre-upgrade report for details and possible remediation.

============================================================
                     UPGRADE INHIBITED                      
============================================================


Debug output written to /var/log/leapp/leapp-preupgrade.log

============================================================
                           REPORT                           
============================================================

A report has been generated at /var/log/leapp/leapp-report.json
A report has been generated at /var/log/leapp/leapp-report.txt

============================================================
                       END OF REPORT                        
============================================================

Answerfile has been generated at /var/log/leapp/answerfile

Diesmal weist die Ausgabe darauf hin, dass ein Upgrade durch fehlende Antworten in /var/log/leapp/answerfile verhindert wird. Die genannte Datei kann mit einem Editor geöffnet und entsprechend bearbeitet werden:

[remove_pam_pkcs11_module_check]
# Title:              None
# Reason:             Confirmation
# =================== remove_pam_pkcs11_module_check.confirm ==================
# Label:              Disable pam_pkcs11 module in PAM configuration? If no, the upgrade process will be interrupted.
# Description:        PAM module pam_pkcs11 is no longer available in RHEL-8 since it was replaced by SSSD.
# Type:               bool
# Default:            None
# Available choices: True/False
# Unanswered question. Uncomment the following line with your answer
confirm = True

Die Datei enthält direkt eine Erklärung, warum das erwähnte Modul zu entfernen ist und wie dies zu geschehen hat.

Anschließend empfiehlt sich ein Blick in den Bericht unter /var/log/leapp/leapp-report.txt, um zu prüfen, ob einem Upgrade evtl. weitere Gründe entgegen stehen. Auf die Ausgabe des Berichts in diesem Artikel wird aus Platzgründen verzichtet. Da der Inhalt auf jedem System unterschiedlich ausfallen kann, ist sein Nutzen an dieser Stelle ohnehin stark begrenzt.

Durchführung des In-Place-Upgrade

An dieser Stelle wird es ernst. Man sollte sich noch einmal vergewissern, dass man einen Snapshot bzw. ein geeignetes Backup des Systems hat. Dann wird das Upgrade mit folgendem Befehl gestartet:

# leapp upgrade
# Ausgabe gekürzt
============================================================
                           REPORT                           
============================================================

A report has been generated at /var/log/leapp/leapp-report.json
A report has been generated at /var/log/leapp/leapp-report.txt

============================================================
                       END OF REPORT                        
============================================================

Answerfile has been generated at /var/log/leapp/answerfile

Dieser Vorgang kann mehrere Minuten dauern. Leapp lädt notwendige Daten herunter und bereitet die RPM-Transaktionen für das Upgrade vor. Dabei wird erneut geprüft, ob Gründe vorliegen, die ein Upgrade verhindern können. Sollte dies der Fall sein, bricht leapp den Vorgang ab und erzeugt einen neuen Bericht.

Ist das Upgrade erfolgreich durchgelaufen, muss das System manuell neugestartet werden. Das System startet anschließend in eine RAM-Disk und aktualisiert alle Pakete des Systems. Anschließend wird automatisch ein Neustart ausgeführt. Dieser Vorgang lässt sich am besten an einer (virtuellen) Konsole beobachten.

Nachdem das Upgrade abgeschlossen ist, kann man sich wieder am System anmelden und mit folgenden Kommandos prüfen, ob das System den gewünschten Status hat (vgl. Kapitel 5 in [0]):

[root@rhel7-t1 ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux release 8.4 (Ootpa)

[root@rhel7-t1 ~]# uname -r
4.18.0-305.12.1.el8_4.x86_64

[root@rhel7-t1 ~]# subscription-manager list --installed
+-------------------------------------------+
    Installed Product Status
+-------------------------------------------+
Product Name:   Red Hat Enterprise Linux for x86_64
Product ID:     479
Version:        8.4
Arch:           x86_64
Status:         Subscribed
Status Details: 
Starts:         06.10.2020
Ends:           06.10.2021

[root@rhel7-t1 ~]# subscription-manager release
Release: 8.4

Hier sieht alles gut aus.

Post-Upgrade-Tasks

Kapitel 6 in [0] beschreibt detailliert, welche Aufgaben nach einem erfolgreichen In-Place-Upgrade noch auszuführen sind, um ein möglichst sauberes System zu erhalten.

Auf meinem Testsystem sind einige RHEL 7 Pakete zurückgeblieben, welche ich mit folgendem Kommando entferne:

# dnf remove `rpm -qa | grep -e '\.el[67]' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)' | sort`
Updating Subscription Management repositories.
Dependencies resolved.
===============================================================================
 Package              Arch       Version                     Repository   Size
===============================================================================
Removing:
 doxygen              x86_64     1:1.8.5-4.el7               @System      15 M
 kernel               x86_64     3.10.0-1160.31.1.el7        @System      64 M
 kernel               x86_64     3.10.0-1160.36.2.el7        @System      64 M
 leapp                noarch     0.12.1-1.el7_9              @System      93 k
 leapp-repository     noarch     0.14.0-4.el7_9              @System     1.7 M
 python2-leapp        noarch     0.12.1-1.el7_9              @System     618 k
 ustr                 x86_64     1.0.4-16.el7                @System     279 k

Transaction Summary
===============================================================================
Remove  7 Packages

Freed space: 146 M
Is this ok [y/N]:

# cd /lib/modules && ls -d *.el7*
3.10.0-1160.25.1.el7.x86_64  3.10.0-1160.36.2.el7.x86_64
3.10.0-1160.31.1.el7.x86_64

# /bin/kernel-install remove 3.10.0-1160.36.2.el7.x86_64 /lib/modules/3.10.0-1160.36.2.el7.x86_64/vmlinuz
# /bin/kernel-install remove 3.10.0-1160.25.1.el7.x86_64 /lib/modules/3.10.0-1160.25.1.el7.x86_64/vmlinuz
# /bin/kernel-install remove 3.10.0-1160.31.1.el7.x86_64 /lib/modules/3.10.0-1160.31.1.el7.x86_64/vmlinuz

Damit ist es geschafft. Das System wurde erfolgreich auf RHEL 8 aktualisiert.

Fazit

Dieser Artikel stellt das RHEL-In-Place-Upgrade vor und nennt kurz einige Gründe, wann dies gegenüber einer Neuinstallation Vorteile bietet. Anschließend wurde das Upgrade an einem Testsystem demonstriert mit dem Ziel, einen Überblick über den Upgrade-Prozess zu geben.

Für In-Place-Upgrades von Produktionssystemen ist ein Blick in die Hersteller-Dokumentation, Backups und sorgfältige Planung unerlässlich.

Das für diesen Artikel verwendete Testsystem besteht lediglich aus einer Minimal-Installation ohne Anwendungen von Dritten. Ob ein In-Place-Upgrade auch mit installierten Anwendungen Dritter funktioniert, hängt vom Einzelfall ab und ist sorgfältig zu prüfen und zu testen.

Erste Versuche mit Web- und Anwendungsservern aus unserer Umgebung konnten mit positivem Ergebnis abgeschlossen worden.

Es gibt Anwendungsfälle, wo ein In-Place-Upgrade vorteilhaft ist. Ich persönlich bevorzuge, wenn möglich und vom Aufwand vertretbar, jedoch die Neuinstallation inkl. Migration der Daten auf einem neuen System. So kann sichergestellt werden, dass keine unentdeckten Altlasten mitgeschleppt werden.

[0] Upgrading from RHEL 7 to RHEL 8. Instructions for an in-place upgrade from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8. Red Hat Enterprise Linux 8. Red Hat Customer Content Services.

[1] Supported in-place upgrade paths for Red Hat Enterprise Linux (Login required)

[2] Red Hat Enterprise Linux technology capabilities and limits

[3] Data required by the Leapp utility for an in-place upgrade from RHEL 7 to RHEL 8 (Login required)

Die Welt war schön und einfach, als Steve Ballmer 2001 Open Source noch zu einem Krebsgeschwür erklärte. Hier die freie Open Source Community, dort die Hersteller proprietärer Systeme. Heute ist die Welt unübersichtlicher geworden und nicht Konzerne wie Microsoft sind das größte Problem, sondern Firmen wie Google.

Bleiben wir beim Bild des Krebsgeschwürs. Balmer meinte in jenem denkwürdigen Interview, dass die freie Lizenz alles anstecken würde, was es berührt, daher der Vergleich mit Krebs. Heute würde ich Google als eben jenen Krebs bezeichnen, denn es befällt alles was es berührt und zerstört es.

Die grundlegende Frage ist letztlich, was ist Open Source und was ist freie Software. Man kann es rein rechtlich und nüchtern per Definition betrachten. In der Auseinandersetzung um die Luca-App hat das auch eine größere Öffentlichkeit erreicht. Open Source ist sachlich betrachtet erst mal nur offener Quellcode, den man einsehen kann. Die Lizenz kann trotzdem proprietär sein. Freie Software ist hingegen offener Quellcode und eine freie Lizenz. Zur besseren Unterscheidung gibt es den Begriff FOSS: Free and Open Source Software. Seltener auch als FLOSS, also Free/Libre Open Source Software bezeichnet.

Kurzum: Alles was unter einer freien Lizenz steht und den Quelltext frei zur Verfügung steht, ist Open Source Software. Bleibt man nahe an dieser Definition, ist es nur ein rechtlicher Vorgang, ob eine freie Lizenz gewählt wird und es kann unmöglich ein Urteil darüber getroffen werden, ob irgendetwas „Open Source“ schadet. Abgesehen von einer Verletzung der Lizenz natürlich. Hier könnte man den Artikel nun beenden.

Das greift aber zu kurz. Open Source steht auch für eine Gemeinschaft und ein Konzept. Ganz wesentlich hat dies in der öffentlichen Wahrnehmung die Entwicklergemeinschaft um den Linux-Kernel geprägt. Eine Gemeinschaft aus Individuen erschafft gemeinsam eine lauffähige Software, die dann frei verfügbar ist. Potenziell kann jeder dazu beitragen und die Software besser machen.

Dieses Konzept und diese Idee hat sich im Laufe der Zeit einen guten Ruf erarbeitet. Freie Software gilt erst mal als etwas Positives und Entwickler, die dazu beitragen, bekommen dasselbe Sozialprestige wie bei anderen Ehrenämtern auch. Dasselbe gilt für Firmen im Open Source-Umfeld.

Und hier kommt Google ins Spiel: Was ist, wenn eine Firma sich dieses Images bedient, den Gedanken bis zur Unkenntlichkeit aushöhlt und die Community mit überlegenen finanziellen Ressourcen ruhig stellt. Gleichzeitig unterwandert sie das Ökosystem bis zur Dysfunktionalität. Denn genau das tut Google.

Als Vergleich lohnt sich ein Blick auf Microsoft und Apple. Insbesondere der Konzern aus Redmond hat ja in den letzten Jahren eine umfassende Open Source Strategie aufgebaut. Die meisten dürften sich z. B. an die Übernahme von GitHub oder die Offenlegung von .NET erinnern. Inzwischen kann man sogar Linux als Subsystem installieren. Trotzdem würde sich kein Microsoft-Manager hinstellen und beispielsweise bei der Ankündigung von Windows 11 irgendwo von einem „freien System, das die Welt besser macht“, sprechen.

Das Gleiche gilt für Apple. Dabei sind seine Betriebssysteme tief im Kern Open Source. Das betrifft nicht nur Darwin, sondern auch viele andere Bestandteile und großzügige Übernahmen aus dem BSD-Universum. Ein Gutteil von macOS (und iOS) steht unter freien Lizenzen. Trotzdem stellt sich kein Apple-Manager hin und behauptet, Apple wäre eine tolle Open Source Company. Da wirft man lieber mit tausend anderen Superlativen um sich.

Anders ist das bei Google. Als Beispiel kann die Darstellung der Geschichte von Android dienen. Mithin das wichtigste Produkt von Google neben der Suchmaschine:

2007

Steve Jobs stellt das erste iPhone vor. Im gleichen Jahr gründet Google gemeinsam mit 33 Partnern aus der Mobilfunkbranche, darunter Samsung, HTC und T-Mobile, die »Open Handset Alliance«. Die Mission: mit Android ein offenes Betriebssystem zu schaffen, das jeder Hersteller und Entwickler kostenlos verwenden und anpassen kann.

Geschichte von Android, abgerufen am 17.09.2021

Das ist ein tolles Beispiel, weil es die Mechanismen von Googles Darstellung zeigt. Ein weiteres Beispiel ist die Open Source Landingpage von Google. Man schafft etwas freies, offenes, kostenloses, mit vielen Partnern und macht die Welt ein bisschen besser. Auch du als Programmierer oder Kunde willst Teil davon sein.

Den Lesern dieses Blogs brauche ich vermutlich nicht erzählen, was für ein Quatsch das ist. Die Open Handset Alliance existiert nur auf dem Papier, faktisch entwickelt Google Android alleine. Die Hersteller werden z. B. mit lukrativen Knebelverträgen verpflichtet, Android mit dem proprietären Google-Ökosystem auszuliefern. Die Kunden in der westlichen Welt wollen Android nur in der Google-Variante. Huawei musste das gerade schmerzlich erfahren.

Und hier nähern wir uns dem Kern des Problems an. Google macht viel mit Open Source, aber die Basis des Geschäftsmodells ist die Bündelung mit proprietären Google-Diensten. Alles was Google am Ende an den Verbraucher bringt, ist letztlich eine Kombination aus Open Source und proprietären Bestandteilen. Weder bei Android noch bei Chrome oder dem neuen Projekt Fuchsia gibt es eine Kooperation mit der Community. Google entwickelt und schmeißt den Quellcode der Community vor die Füße. Das unterscheidet sich nahezu gar nicht von der Art, wie Apple Darwin veröffentlicht. Die Community kann dann schauen, was sie damit macht. Bei Android hat die famose Custom ROM-Szene ein lauffähiges freies Android entworfen, auf Basis des Chrome-Quellcodes sind viele Browser entstanden und mal sehen, was Fuchsia so bringt. Bei ChromeOS hat man erst die Gemeinschaft entdeckt, als man merkte, dass man mit reinen WebApps nicht weiter kommt. Die maschinelle Übersetzung auf Googles Seite ist verblüffend ehrlich:

Linux ist eine Funktion, mit der Sie Software auf Ihrem Chromebook entwickeln können.

Chromebook Hilfe, abgerufen am 17.09.2021

Dass ChromeOS ein angepasstes Linux ist und ohne die Community nicht denkbar wäre wird mit keinem Wort auf der gesamten Seite erwähnt.

Gleichzeitig gerät die Gemeinschaft in eine massive Abhängigkeit von Google. Ich glaube, dass die Existenz von Android ein Grund ist, warum lange kein freies Linux-Smartphone entwickelt wurde und die Projekte noch immer in den Kinderschuhen stecken. Es gab ja bereits ein „Linux-Betriebssystem für Smartphones“. Ganz offenkundig ist es mit Chrome. Die Existenz von Chromium hat viele Projekte dazu gebracht, auf den Google-Vorarbeiten aufzusetzen. Qt hat gar sein eigenes WebKit eingestampft und ist auf Chromium gewechselt. Doch was passiert, wenn Google Chrome morgen aufgibt oder mit Fuchsia sich von den Linux-Wurzeln löst?

Die FOSS-Community wird gleichzeitig mit Projekten wie GSoC ruhig gestellt. Nachwachsende Generationen von Programmierern werden gleich mit einer positiven Einstellung zu Google herangezogen (bei Journalisten macht Google das übrigens genau so) und die OSS-Projekte sind viel zu knapp an Ressourcen, um sich den Avancen von Google zu widersetzen.

Sind Firmen wie Microsoft oder Apple besser? Nein, aber sie sind ehrlicher. Sie behaupten nicht, freie Software zu entwickeln und wenn sie es machen, stellen sie es nicht so extrem ins Schaufenster. Es sind proprietäre Firmen und es gibt mit der FOSS-Gemeinschaft etablierte Verfahren der Koexistenz. Wenn Apple Darwin morgen einstampft, ist das für den Fortbestand von FOSS unkritisch, mit Abstrichen würde das auch für den fiktiven Fall gelten, dass Microsoft GitHub abschaltet.

Wenn Google morgen jedwedes Engagement für FOSS einstellt, dürfte das anders aussehen. Und die Abhängigkeit wird jedes Jahr größer.

Und bei dieser Betrachtung haben wir noch nicht mal in den Blick genommen, dass die FOSS-Gemeinschaft mit einer Firma ins Bett steigt, deren Geschäftsmodell die vielleicht größte Bedrohung für die Privatsphäre und den Datenschutz der Menschen in der westlichen Welt (neben den Aktivitäten staatlicher Stellen) darstellt.

Von „Don’t be evil“ hat Google sich ja wohlweislich vor einiger Zeit verabschiedet.

Der Artikel Warum Google für FOSS gefährlich ist erschien zuerst auf [Mer]Curius

Firefox wird in den meisten Ländern der Welt mit Google als Standard-Suchmaschine ausgeliefert. Aktuell testet Mozilla, wie sich eine Änderung der Standard-Suchmaschine auf Microsoft Bing auf die Nutzung von Firefox auswirkt.

Die meisten Browser werden bereits mit mehreren Suchmaschinen ausgeliefert. Auch hat der Nutzer jederzeit die Möglichkeit, weitere Suchmaschinen zu installieren. Das Thema Standard-Suchmaschine, sprich welche Suchmaschine genutzt wird, wenn der Nutzer keine Änderung vornimmt, ist von besonderer Bedeutung. Denn daran hängt üblicherweise zu einem großen Teil auch die Finanzierung des Browsers. Im Falle von Firefox beispielsweise hat die Vergütung für die Standard-Suchmaschine 88 Prozent von Mozillas Gesamt-Umsatz im Jahr 2019 ausgemacht.

Siehe auch: Mozillas Einnahmen, Ausgaben und Vermögen von 2005 bis heute

Fast schon traditionell wird Firefox mit Google als Standard-Suchmaschine ausgeliefert – zumindest in den meisten Ländern. Nur zwischen 2014 und 2017 fiel die Wahl auf Yahoo. Der aktuelle Vertrag zwischen Mozilla und Google soll im August 2020 um weitere drei Jahre verlängert worden sein.

Doch was bringt die Zukunft? Wie viel ist es Google über das Jahr 2023 hinaus noch wert, Standard-Suchmaschine in Firefox zu sein? Zumal Mozilla kontinuierlich weitere Datenschutz-Verbesserungen in Firefox ausliefert und Google mit Chrome ebenfalls einen Browser anbietet, der mittlerweile eine unglaublich hohe Dominanz besitzt, Tendenz weiter steigend. Es erscheint also nur logisch, dass sich Mozilla mit einem möglichen Zukunfts-Szenario beschäftigt, welches ohne Google stattfindet.

So findet seit diesem Monat ein Experiment statt, in dessen Rahmen die Standard-Suchmachine für einen Prozent der Desktop-Nutzer von Firefox auf Microsoft Bing verändert wird. Dieser Test, der Erkenntnisse darüber liefern soll, inwieweit eine Änderung der Standard-Suchmaschine Einfluss auf die Nutzung von Firefox hat, wird vermutlich bis Ende Januar 2022 laufen.

Der Beitrag Mozilla testet Microsoft Bing als Standard-Suchmaschine in Firefox erschien zuerst auf soeren-hentzschel.at.

Fr, 17. September 2021, Ralf Hersel

Eine Feature Freeze Exception (FFE), die von Olivier Tilloy (Canonical) eingereicht wurde, wird das Firefox deb-Paket in Ubuntu 21.10 (Impish Indri) wahrscheinlich durch die Snap-Version des Webbrowsers ersetzen.

Tillay schreibt:

"Gemäss der Vertriebsvereinbarung von Canonical mit Mozilla machen wir Snap zur Standardinstallation von Firefox auf Desktop-ISOs, beginnend mit Ubuntu 21.10."

Firefox wird derzeit über die Ubuntu-Repos als deb-Paket verteilt. Sollte dem Antrag stattgegeben werden, erhalten Ubuntu-Anwenderinnen mit der Version 21.10 ab Ende Oktober den Webbrowser Firefox standardmässig als Snap-Paket installiert.

Zur Begründung schreiben die Beteiligten Canonical und Mozilla:

Dies ist das Ergebnis der Kooperation und Zusammenarbeit zwischen den Ubuntu-Desktop- und Snap-Teams bei Canonical und den Mozilla-Entwicklern und ist der erste Schritt zu einem Deb-to-Snap-Übergang, der während des 22.04-Entwicklungszyklus stattfinden wird.

Als Vorteil nennt Canonical schnellere Update-Zeiten, weil das Packen, Testen und Hochladen des Deb-Paketes entfällt und stattdessen Mozilla direkt für das Snap-Paket verantwortlich ist. (Müssen die nicht auch Packen, Testen und Hochladen?)

Neue Installationen von Ubuntu 21.10 (sowie diejenigen, die von Ubuntu 21.04 Upgraden) werden das Firefox-Snap-Paket als Standard erhalten. Damit handeln sich die Ubuntu-Anwender auch einen Performance-Nachteil ein. Obwohl das Snap-Team seit langem daran arbeitet, die Startgeschwindigkeit von Snaps zu verbessern, sind diese immer noch signifikant langsamer als native Pakete (deb) und auch Flatpaks.

Der wichtigste Punkt in Canonicals Ankündigung ist jedoch der Hinweis auf den Deb-to-Snap Übergang, den Canonical für und ab der nächsten LTS-Version 22.04 plant. Damit entfernt sich Ubuntu ein Stück weiter von der FLOSS-Community mit diesem Eigenweg. Canonical ist bekannt für mutige Versuche und erfolglose Resultate: Unity, MIR, Ubuntu-Touch, Ubuntu-TV, Snap, ... Was es auch war, es war immer ein Arbeiten unter Ausschluss der Community.

Ich denke, dass gemeinsame Paketformate der heilige Gral der GNU/Linux-Idee sind. Paket-Repositories sind für mich der Hauptgrund für den Erfolg von Linux-Distros. Alle anderen Betriebssysteme haben dieses Konzept von GNU/Linux kopiert: Apples App Store, Googles Play Store, Microsofts Windows Store. Die Linux Community ist zurzeit damit beschäftigt, ihren grössten Vorteil zu zerstören, indem Anwender-Interessen gegen Entwickler-Interessen ausgespielt werden. Die nativen Repos werden gegen die Container-Formate abgewogen. Im Moment sieht es so aus, als würden die nativen Formate bestehen bleiben und Flatpak als einziges Container-Format den Wettbewerb gewinnen. AppImages und Snaps scheinen die Anwender nicht zu überzeugen.

Quelle: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1943840

Was ist eure Meinung dazu?

Diskutiere mit der Community oder schreibe bei uns mit!

Fr, 17. September 2021, Denys Konovalov

Die meisten Menschen werden zustimmen, dass Linux Mint eine der einsteigerfreundlichsten und, besonders unter Windows-Umsteigern, beliebtesten Distributionen ist. Doch die Website von Linux Mint war lange veraltet und schreckte neue Nutzer*innen teils ab. Jetzt hat das Projekt endlich eine neue Website vorgestellt, welche allen modernen Standards entspricht, und den Ersteindruck über Linux Mint bei vielen Neulingen sehr verbessern wird.

Im jetzigen digitalen Zeitalter gehört zu jedem seriösen Projekt eine entsprechend gut gestaltete Website, besonders wenn man sich an Einsteiger richtet.

Bei Linux Mint entsprach die alte Website schon lange nicht mehr dem angebotenen Produkt.

Doch jetzt präsentiert Mint sich modern, mit einer Website, die einheitlich im Linux-Mint-Grün gehalten den neusten Design-Trends entspricht und natürlich auch adaptiv ist.

Die neue Website macht vieles richtig, was die anderen nicht beachten: Man spricht die Zielgruppe an, an welche man sich richtet. Die Seite konzentriert sich darauf, einem Neuling zu erklären, was Linux Mint ist, und welche Gründe es gibt, das System auszuprobieren.

Auf die wichtigsten Einsteigerfragen, wie z. B. "Kann ich mein Windows behalten?", wird direkt geantwortet.

Wo Ubuntu über Kubernetes und den Enterprise-Bereich spricht, redet Mint über das, was einen normalen Desktop-Nutzer interessiert.

Insgesamt macht die neue Website den Eindruck, man habe sich damit auseinandergesetzt, worum sich Einsteiger*innen sorgen, und einfache Antworten auf die wichtigsten Fragen geben wollen.

Auch wenn das nicht die große Umstiegswelle auslösen sollte, wird die neue Seite sicherlich so manch einem Unentschlossenen die Sorgen nehmen und dazu bewegen, Linux zumindest zu versuchen.

Was haltet ihr von der neuen Website? Denkt ihr, eine neue Seite war das, was Linux Mint noch gefehlt hat, oder findet ihr, die neue Website wird nichts ändern? Haltet ihr es für wichtig, die Sorgen der Nutzer*innen gleich am Anfang anzusprechen? Diskutiert mit uns!

Diskutiere mit der Community   oder   Schreibe bei uns mit!

Quellen:

• https://linuxmint.com

Mozilla hat Version 2.5 seiner VPN-Clients für das Mozilla VPN veröffentlicht. Damit kommen, neben anderen Neuerungen, auch Features wie ein Werbeblocker, Anti-Tracking und Multi-Hop. Dieser Artikel beschreibt die Neuerungen vom Mozilla VPN 2.5.

Mit dem Mozilla VPN bietet Mozilla in Zusammenarbeit mit Mullvad sein eigenes Virtual Private Network an und verspricht neben einer sehr einfachen Bedienung eine durch das moderne und schlanke WireGuard-Protokoll schnelle Performance, Sicherheit sowie Privatsphäre: Weder werden Nutzungsdaten geloggt noch mit einer externen Analysefirma zusammengearbeitet, um Nutzungsprofile zu erstellen.

Jetzt Mozilla VPN nutzen

Die Neuerungen vom Mozilla VPN 2.5

Werbeblocker, Anti-Tracking, Benutzerdefinierter DNS-Server

Neben dem Standard-DNS lassen sich in den Erweiterten DNS-Einstellungen jetzt auch andere DNS-Optionen wählen: Ein DNS-Server, welcher Werbung blockiert, ein Anti-Tracking-DNS oder ein DNS-Server, der beides kombiniert. Und wer einen lokalen DNS-Server einsetzen möchte, kann dies hier ebenfalls konfigurieren. Dieses Feature steht auf allen Plattformen zur Verfügung.

Multi-Hop: Mehrere Stationen

Standardmäßig leitet das Mozilla VPN den Datenverkehr über einen Server an einem Standort. Das neue Multi-Hop-Feature erlaubt es, den Verkehr von einem Standort über einen anderen Standort zu leiten, quasi ein VPN nach dem VPN. Dieses Feature steht unter Windows, MacOS und Linux zur Verfügung.

Sonstige Neuerungen

Support-Tickets können nun innerhalb des VPN-Clients abgesendet werden. Auf Android kann das VPN-Abonnement jetzt auch innerhalb der App verwaltet werden. Für neue Nutzer gibt es eine neue Feature-Tour beim ersten Start.

Das Einstellungs-Menü wurde neu organisiert. Die Auswahl des Server-Standorts hat zum schnelleren Finden eine Suchleiste erhalten. Die bei der Verbindung benötigten System-Ressourcen wurden reduziert. Potentiell sensible Daten, welche in die Log-Dateien geschrieben werden, werden jetzt verschleiert.

Der Beitrag Mozilla VPN 2.5 bringt Werbeblocker, Anti-Tracking und Multi-Hop erschien zuerst auf soeren-hentzschel.at.

Do, 16. September 2021, Ralf Hersel

Die Distribution Solus war schon immer ein Sonderfall. Vielleicht erinnert ihr euch an die endlosen Diskussionen um Ikey Doherty. Solus ist eine Linux-Distribution, die von Grund auf neu entwickelt wurde. Sie verwendet eine geforkete Version des PiSi-Paketmanagers, der innerhalb von Solus als "eopkg" genannt wird, und eine eigene, selbst entwickelte Desktop-Umgebung namens "Budgie" bereitstellt. Der Budgie-Desktop, der so eingestellt werden kann, dass er das Aussehen des GNOME-2-Desktops emuliert, ist eng mit dem GNOME-Stack integriert. Ihr erkennt den Sonderfall: eigene Distro, eigener Desktop!

Nun kündigt Joshua Strobl (Hauptentwickler im Solus-Team) ein "alternatives Ecosystem" an. Das sind grosse Worte aus dem Team einer exaltierten GNU/Linux-Distribution. Im Kern handelt es sich bei der Neuausrichtung um eine Abrechnung mit der GNOME-Philosophie, den GNOME-Entwicklern und den Umgangsformen im GNOME-Projekt. Eine Abrechnung, die zum Solus-Projekt passt. Hier seht ihr die Zusammenfassung der Gründe, um sich von GTK abzuwenden und stattdessen die Enlightment Library (EFL) zu bevorzugen.

Joshua fasst es so zusammen:

• GTK4 hat seit seiner Veröffentlichung im Dezember 2020 weder unsere Erwartungen erfüllt, noch sind wir mit seinem Zustand zum Zeitpunkt der Erstellung dieses Beitrags zufrieden.
• Die aktuellen Pläne von GNOME für Änderungen an der Art und Weise, wie das Theming funktioniert, betrachten wir als Rückschritt für Desktop-Linux, Entwickler und Benutzerauswahl.
• Wir glauben nicht, dass GNOME seine Gemeinschaft, von einzelnen Nutzern bis hin zu ganzen Betriebssystemen, in einer Weise behandelt, die gerecht ist und ihre Wahl respektiert, wie sie ihre eigene Erfahrung gestalten wollen.
• Budgie 11 wird nicht in GTK4 geschrieben werden.
• Für die Budgie-Edition: Wir werden daran arbeiten, von GNOME entwickelte Software durch die von alternativen Softwareentwicklern sowie durch "hauseigene" Lösungen zu ersetzen. Diese werden nicht notwendigerweise unter der GetSolus-Organisation stehen und auch nicht mit Budgie in Verbindung gebracht werden. Um Budgie in Zukunft einzusetzen (zumindest bis 11, wenn wir unser eigenes Kontrollzentrum haben), ist es nicht erforderlich und wird es auch nicht sein, unsere eigenen Anwendungen zu verwenden. Dies gilt sogar für Budgie Desktop View, wir unterstützen Alternativen wie Desktop Folder als alternative "Desktop"-Implementierungen in Budgie.
• Die GNOME-Edition wird in einer zukünftigen Version von Solus zu einer nicht-kuratierten Edition degradiert und auf unserer Download-Seite in eine untergeordnete Position verschoben.

Das sind starke Worte und konsequente Entscheidungen, die es zu respektieren gilt. Die vollständige Begründung findet ihr in seinem Post "Building an alternative Eco-System". Ob das der richtige Weg ist, wird die Community entscheiden. Vor einigen Jahren war Solus eine geschätzte und beachtete Distribution. Nach den Ikey-Querelen nahm das Interesse schnell ab. Ob das Loslösen von GNOME, bzw. GTK, die Solus-Distro wieder in die Aufmerksamkeit der Anwenderinnen bringen kann, bleibt abzuwarten.

Quelle: https://joshuastrobl.com/2021/09/14/building-an-alternative-ecosystem/

IRC ist ein wenig aus der Mode gekommen, aber wird in der FOSS-Welt immer noch rege genutzt. In meiner Desktop-Vorstellung hatte ich über HexChat geklagt. Daraufhin hat mir ein Leser Srain empfohlen. Den Tipp möchte ich euch nicht vorenthalten.

KDE hat mit Konversation wirklich eine tolle Lösung. Bei GNOME gibt es Polari aber das unterstützt nicht mal eine ordentliche Authentifizierung. Bleibt nur HexChat, der gute alte Gtk2-Dinosaurier. Dachte ich jedenfalls. Mit Srain steht jedoch ein moderner Gtk3-basierter Client ohne direkte GNOME-Anbindung zur Verfügung.

Authentifizierung über NickServ oder SASL wird unterstützt und das ist wirklich die einzige für mich absolut essenzielle Funktion. Ansonsten ist der Client funktional eher schmal ausgestattet, aber wird aktiv gepflegt. In dem Software-Bereich durchaus ein hervorzuhebender Aspekt.

Die Optik mit den Sprechblasen, wie man sie von modernen Messengern kennt, ist ein wenig gewöhnungsbedürftig, aber ansonsten erledigt Srain seine Aufgabe tadellos.

Ob Srain auch für Poweruser reicht, kann ich nicht beurteilen. Aber gibt es die für IRC überhaupt noch?

Der Artikel Srain – Moderner Gtk3-basierter IRC Client erschien zuerst auf [Mer]Curius

Mo, 13. September 2021, Norbert Rüthers

Als grosser Freund von exotischen und alternativen Betriebssystemen (früher Amiga OS) liebäugele ich schon lange mit HAIKU. Angeregt durch mehrere Podcasts von Radiotux (zuletzt August 2021) habe ich mich jetzt entschlossen die aktuelle R1 Beta 3 Version von HAIKU ausgiebig zu testen.

HAIKU ist die Weiterführung des früheren Be OS. Haiku ist ein Betriebssystem, dass versucht das BeOS, was im Jahr 2001 eingestellt wurde nachzuprogrammieren und dessen Innovationen und Vorteile in die Gegenwart zu transferieren. BeOS wurde am Ende der 90iger Jahre von der kleinen Firma Be Inc.entwickelt, die von dem ehemaligen Apple Mitarbeiter Jean-Louis Gassée gegründet wurde. BeOS wurde von Grund auf neu entwickelt mit dem Ziel ein schnelles, schlankes Multimedia Betriebssystem zu haben. Wer mehr zu den geschichtlichen Hintergründen erfahren will, dem empfehle ich diesen Artikel. Bereits früher in der Beta 1 Version hatte ich HAIKU kurz auf der Platte aber vieles funktionierte noch nicht so richtig und so vergingen ein paar Jahre bis zum jetzigen Test. HAIKU hat nun R1 Beta 3 erreicht und vieles läuft deutlich besser. Die Installation ist recht einfach und läuft mithilfe des Installation Guide sehr zügig. Wer HAIKU nicht gleich installieren will, hat auch die Möglichkeit es live vom USB Stick zu starten und einen ersten Eindruck zu bekommen.Wer Windows oder Linux gewohnt ist, wird sich erstmal staunend zurücklehnen. Die Oberfläche hat so gar nichts von dem, was man landläufig gewohnt ist. Die Fenster haben komplett andere Steuerelemente und ein konventionelles Startmenü sucht man vergebens. Die Lernkurve verläuft aber recht steil und schon nach kurzer Zeit kann man mit dem System arbeiten.

Die Geschwindigkeit und minimalen Systemansprüche beeindrucken ebenfalls. Bereits mit minimalem Arbeitsspeicher (ca. 1 GB) läuft HAIKU problemlos. Deshalb bietet es sich geradezu für ältere Rechner an, aber auch aktuelle Rechner werden unterstützt. Interessant war zu erfahren das HAIKU auch heute im professionellen Einsatz z.B. bei Radiosendern ist.

Ein paar Eindrücke vom Aussehen des Desktops

Quelle: HAIKU OS

Wem die Auswahl der vorinstallierten Programme nicht reicht, findet viele bekannte Programme im "HAIKU Depot". Haiku hat viel Potenzial, vor allen Dingen von einigen geerbten BeOS Features, aber auch sehr konsequenter und durchdachter Weiterentwicklung.

Fazit: Die Wurzeln von HAIKU reichen zwar lange zurück, aber es ist nicht retro, sondern hat die Vorzüge der Vergangenheit in die Gegenwart portiert.

Also einfach mal ausprobieren und Freunde und Bekannte verblüffen

Der Download der 32 Bit und 64 Bit Version erfolgt von der HAIKU Webseite

PS: erst als dieser Artikel fertig war erfuhr ich das schon andere Artikel zu diesem Thema hier erschienen sind. Besonders Niklas hat mit seiner mehrteiligen Serie gute Einsteigerinfos geliefert

Die beliebte Distribution Manjaro ersetzt in der Cinnamon-Variante Firefox als Standardbrowser durch den Chromium-Fork Vivaldi. Das kündigte der Browser-Hersteller vor einigen Tagen an. Kommt nun eine Lawine ins Rollen?

Linux gehört zu den letzten Refugien für Firefox. In allen anderen Bereichen ist der freie Browser bereits massiv unter Druck geraten oder hat – wie im mobilen Segment – nie ernsthaft Fuß fassen können. Wie bedenklich diese Entwicklung ist, wurde hier vor Kurzem bereits thematisiert.

Natürlich kann die Abkehr in einer Manjaro-Variante ein singuläres Ereignis bleiben. Frühere Entscheidungen, wie z. B. die Option SoftMaker Office anstelle von LibreOffice zu wählen, haben zwar viel Aufsehen erregt, aber wenig Nachahmer gefunden.

Es steht aber zu befürchten, dass das dieses Mal anders sein könnte. Viele Entwickler sind eng mit dem Google-Ökosystem verbandelt. Durch finanzielle Förderung oder intensive Nutzung der Dienste. Viele Anwender installieren schnell nach der Ersteinrichtung Chrome oder Chromium nach.

Während die Distributoren auf veränderte Nutzungsgewohnheiten normalerweise schnell reagieren, haben sie hier erstaunlich lange an Firefox festgehalten. Umso mehr steht nun zu befürchten, dass die Distributoren dieser Entwicklung Rechnung tragen und die Standardauswahl ändern. Auf die kleine aber beliebte Distribution Manjaro könnten andere wichtigere Distributoren folgen.

Vivaldi ist letztlich nur ein Chromium-Fork und ohne Googles Entwicklungsleistung nicht lebensfähig. Ob Manjaro nun zu Vivaldi oder direkt zu Chromium wechselt ist für die Bewertung daher völlig bedeutungslos. Der Markt ist klar aufgeteilt: Es gibt nur noch Firefox oder die Google-Browser mit verschiedenen Brandings.

Die Zeiten werden nicht einfacher. Weder für Firefox noch für Datenschutz und Privatsphäre im Netz und ein freies Internet allgemein.

Der Artikel Manjaro ersetzt Firefox – Beginn einer Lawine? erschien zuerst auf [Mer]Curius

Google unterstützt freie und offene Schnittstellen in seinem Betriebssystem Android überhaupt nicht, um die Anwender an die eigenen Dienste zu fesseln. Die Community kompensiert dies mit eigenen Apps. Nun gibt es auch endlich eine freie WebDAV App.

Bei Apple rufen immer alle „Goldener Käfig“ (was selbstredend totaler Quatsch ist), aber bei Google schaut keiner so genau hin. Kein Wunder, hat Google doch konsequent die FOSS-Community unterwandert und korrumpiert. Dabei unterstützt Googles Android freie und offene Schnittstellen wie CalDAV, CardDAV oder eben auch WebDAV viel schlechter als Apples Betriebssysteme.

Die Motivation dahinter ist klar: Man möchte die Anwender im eigenen Dienste-Universum halten und hat kein Interesse, Schnittstellen zu implementieren, an denen andere Dienstanbieter andocken können.

Um Kontakte und Kalender zu synchronisieren, greifen die meisten Privatsphäre- und Datenschutz-bewussten Anwender auf DAVx5 zurück. Daran hat man sich schon so sehr gewöhnt, dass diese Leerstelle im Basis-System den meisten Anwendern gar nicht mehr bewusst ist. Leider unterstützt die App keinen Dateiaustausch via WebDAV.

Im lokalen Netz ist das egal, weil hier mit SMB oder NFS bessere Netzfreigaben zur Verfügung stehen. Anders sieht es beim Zugriff über das Internet aus. WebDAV ist zwar langsam und bietet keine Synchronisation, es ist aber vor allem für gelegentliche Cloud-Verbindungen praktischer als ein vollwertiger Sync-Client.

Im Google Play Store gab es immer ein paar mehr oder minder gute Apps für WebDAV, aber bei F-Droid gab es überhaupt kein entsprechendes Angebot.

Diese Leerstelle ist nun endlich geschlossen. Mit RCX existiert nun ein RClone auf F-Droid. Es ist letztlich eine Dateimanager-App, die eine Vielzahl an Clouddiensten anbinden kann, unter anderem eben auch WebDAV. Die Daten in verbundenen Cloud-Speichern können dabei auch in ein lokales Verzeichnis synchronisiert werden.

Der Artikel App-Hinweis: WebDAV App auf F-Droid erschien zuerst auf [Mer]Curius

In diesem Blog schreibe ich über viele Themen, die Privatsphäre, Sicherheit und freie Software tangieren. Mir ist aufgefallen, dass ich aber noch nie über mein persönliches Desktop-Setup geschrieben habe. Das soll hiermit nachgeholt werden.

Ein paar Einblick in mein Nutzungsverhalten gebe ich traditionell am Ende des Jahres in der Artikelserie „Wasser predigen, Wein trinken?„. Dort geht es allerdings über alle Endgeräte und Dienste und nicht nur über den Desktop. Heute möchte ich deshalb ein bisschen über mein persönliches Setup schreiben und warum das so ist.

Ich freue mich über solche Artikel auch in anderen Blogs immer, weil man da oft auf spannende Tools und Lösungen trifft, die man vorher nicht auf dem Schirm hatte.

Hardware, Distribution und Konfiguration

Ich habe viele Jahre mit einem Notebook und einem stationären Desktop-PC gearbeitet. Im letzten Jahr bin ich unter die Wochenendpendler gegangen und musste schnell feststellen, wie unpraktisch so ein Setup ist. Man hat immer die notwendigen Daten auf dem Gerät, an dem man gerade nicht sitzt. Die Hardware war zum Glück sowieso reif für einen Austausch und somit stieg ich im Winter wieder auf ein Notebook als alleiniges Gerät um. Die Wahl fiel auf ein HP EliteBook. Mit diesem bin ich sehr glücklich und kann die Reihe allen ans Herz legen, die gerne ein solides Business-Gerät haben möchte, aber mit ThinkPads fremdeln. Mittels einer USB-C Docking-Station wird das Notebook am Schreibtisch dann zu einem vollwertigen Arbeitsplatzrechner.

Als Distribution ist seit vielen Jahren openSUSE meine erste Wahl. Momentan in der Tumbleweed-Variante, weil auch die aktuelle Leap-Version wegen des alten Kernels meine Hardware nicht optimal unterstützt. Bei der Entscheidung für openSUSE spielen natürlich subjektive Präferenzen eine Rolle. Ich mag die manchmal eigenwilligen Entscheidungen und die Idee etwas voranzubringen, wie z. B. der frühe Einsatz von btrfs mit der tollen Snapshot-Lösung. Dadurch bietet openSUSE wirkliche Mehrwerte gegenüber anderen Distributionen. Es gibt aber auch ein paar harte Fakten. Im Gegensatz zu vielen Hobby-Distributionen unterstützt openSUSE SecureBoot vorbildlich und bietet mit Trusted Boot in Kombination mit dem TPM interessante weitere Entwicklungsmöglichkeiten.

Vermutlich ist es unnötig zu erwähnen, dass das System natürlich komplett mit LUKS verschlüsselt ist. Allerdings mit einem traditionellen Setup ohne verschlüsselte Boot-Partition, weil ich wirklich zu wenig Geduld für die >30 Sekunden Denkpause von GRUB habe. Hier möchte ich demnächst mal mit den neuen Möglichkeiten von systemd für TPM und FIDO experimentieren.

Desktop und Programme

Seit ich 2007 zu Linux kam, habe ich immer mit KDE gearbeitet. Hier und da mal ein Blick über den Tellerrand, aber letztlich immer wieder zurückgekehrt. Das hat sich inzwischen geändert.

Mich haben nicht die vielen Fehler oder das Gefühl auf einer Dauerbaustelle zu arbeiten vertrieben, sondern die Usability. KDE hatte immer viele Optionen und das ist gut so, aber je mehr Einstellungsmöglichkeiten, desto wichtiger wird eine konsistente UX. Wenn alle Programme ähnlich funktionieren, ist das schon die halbe Miete. Was das bei KDE früher bedeutete, kann man heute noch bei Kontact beobachten. Ja, das sind viele Optionen, aber sie in Rubriken und Reiter aufgeteilt und diese Einstellungsdialoge sahen mal bei jeder KDE-Komponente gleich aus. Heute herrscht da nur noch Wildwuchs, von ein paar Hobby-Designern in der VDG wahllos zusammen gefügt. Die Systemeinstellungen sind eine krude Mischung aus alten Elementen, neuen mobilen Varianten und irgendwelchen hineinfahrenden Dialogen. Buttons kleben irgendwo und Mauswege hat sie noch nie jemand angeguckt. Wegen eines Fehlers mit der Wayland-Session musste ich zuletzt häufiger mal den SDDM-Autologin konfigurieren. Das ist eine irrsinnige verschachtelte Konstruktion, die Microsoft in Windows 10 nicht schlechter hätte umsetzen können. Das neue KHamburger-Menü löst die alten Menüs ab, aber nicht so richtig, weil man alle Elemente in das Menü integriert. In den macOS-Jahren habe ich gute UX zu schätzen gelernt, dieses stümperhafte Chaos habe ich einfach nicht mehr ertragen.

Ich habe dann tatsächlich mal ein paar Wochen GNOME probiert. Leider ist die Idee der GNOME-Entwickler von einer guten Desktop-Experience das genaue Gegenteil meines Workflows. Ich brauche circa 8-10 Extension, um mit GNOME arbeiten zu können. Das bricht dann bei jeder neuen GNOME-Version zusammen, weil die Entwickler erklärtermaßen keine Rücksicht auf die Extensions legen. MATE ist zwar nett und mit Plank auch sehr funktional zu nutzen, aber so ein paar grafische Effekte mag ich dann doch haben.

Statt GNOME bin ich dann bei der Pantheon Shell gelandet. Wie ich schon häufiger schrieb, finde ich die Pantheon Shell das bessere GNOME. Allerdings nicht mit elementary OS, sondern in Form der OBS-Pakete. Das ist nicht optimal und würde ich Dritten wohl auch nie empfehlen, aber für mich funktioniert es aktuell am besten. Alternativ kann man die Pantheon Shell auch mit Arch Linux und Fedora nutzen. Beide Distributionen haben sie in den Paketquellen.

Folgende Programme nutze ich auf dem Desktop:

Aufgabe	Programm
Office	SoftMaker Office 2021
Scannen	Vuescan
Finanzen	moneyplex
Dokumentenbetrachter	Evince
PDF-Bearbeitung	PDF Arranger
Bildbearbeitung	GIMP & Image Optimizer
Bildbetrachter	Pantheon Photos
Notizen	Synology Notes & Minder
Cloud	Synology Drive
Browser	Firefox & Tor Browser Bundle
Feedreader	Communique mit FreshRSS Sync
E-Mail, Kontakte und Terminorganisation	Evolution
IRC	HexChat
Aufgaben	Pantheon Tasks
FTP	Filezilla
Musik	Pantheon Music
Video	Pantheon Video
Editor	Code
Virtualisierung	VirtualBox
Passwortverwaltung	KeePassXC
Navigation	GNOME Maps
Backup	Déjà Dup & GRSync
Sonstiges	Pantheon Terminal; Pantheon Files; Pantheon Screenshots; Pantheon Calculator; Catfish; AnyDesk; usw. usf.

Ich arbeite traditionell streng Aufgaben-orientiert. An irgendwelchen Programmen festzuhalten, die für KDE entwickelt wurden und diese unter einer anderen Desktopumgebung zu nutzen, mag theoretisch klappen, funktioniert aber meist nicht gut. Deshalb verwende ich unter jedem Betriebssystem und jedem Desktop die dazu passenden Programme.

Der Vorteil an der Pantheon Shell ist, dass man sich ziemlich viel im GNOME-Ökosystem bedienen kann. Die Qualität der Gtk/GNOME-Programme ist durchschnittlich höher als der Qt/KDE-Pendants. Beispielsweise wenn man Kontact mit Evolution vergleicht. Andere Programme wie GNOME Maps sind viel fokussierter als Marble. Mit Marble kann man theoretisch ganz viel machen, praktisch habe ich es nur als OpenStreetMap-Oberfläche gebraucht und alle anderen Funktionen haben meinen Workflow gestört.

Kern meiner Organisation ist eine stabile PIM-Suite, hierbei ist vor allem die Integration mit einem Synology NAS wichtig, über das ich Kontakte-, Kalender- und Dateisynchronisation vornehme. Das klappt mit Evolution hervorragend und weil Pantheon sowieso auf den Evoluton Data Server zurückgreift, integriert sich Evolution auch in die Shell. Evolution unterstützt nebenbei mit Offline-IMAP und PGP (sofern ich doch mal eine verschlüsselte E-Mai versende oder empfange) zwei Nice-to-have Features.

Die Anwendungen des elementary Projekt nutze ich abgesehen von der Pantheon Shell nur sehr ausgewählt, weil diese oft nicht ausgereift sind. Aufgaben („Tasks“) ist eine wirklich nette Aufgabenverwaltung für CalDAV-Konten, Screenshots, Terminal und Taschenrechner tun ihren Dienst. Bei Musik und Video bin ich so anspruchslos auf dem Desktop, dass es die minimalistischen elementary-Programme für mich tun.

Backups erfolgen auf verschlüsselte externe Platten und mein NAS. Dazu nutze ich rsync oder irgendein Frontend für rsync (LuckyBackup oder Grsync), um auf externe Festplatten zu sichern und zusätzlich sichere ich mittels Déjà Dup auf mein Synology NAS.

Bei virtuellen Maschinen bin ich total faul. VirtualBox mag nicht hip sein und man kann aus Qemu, KVM usw. vielleicht mehr Performance raus kitzeln, aber VirtualBox ist idiotensicher. 3-4 Klicks und meine VM läuft. Egal ob Windows oder irgendein Linux.

Eine großer Verlust beim Wechsel aus dem KDE-Lager in alternative Ökosysteme ist der Verzicht auf Dolphin. Meiner Meinung nach der beste Dateimanager überhaupt. Nicht nur für Linux, sondern auch im Vergleich mit allem was Windows und macOS zu bieten haben. HexChat ist im Vergleich zu Konversation auch eine ziemliche Krücke, aber so selten, wie ich noch im IRC bin, reicht es aus.

Vielleicht haben ja auch andere mal Lust über ihr Setup zu bloggen oder zu kommentieren.

Der Artikel Mein Linux-Desktop erschien zuerst auf [Mer]Curius

Da ich einen XMPP server betreibe muss ich manchmal Probleme mit s2s (server zu server Kommunikation) debuggen. Dazu gehört es auch, zu prüfen ob die SRV records im DNS richtig gesetzt sind und ob ein XMPP server auf diesen ports lauscht.

Da mir das Prüfen der SRV records mit dig und host und das Prüfen der Verbindung mit testssl.sh zu umständlich war habe ich mir ein kleines tool geschrieben: xmpp-dns.

Mit xmpp-dns kann man einfach die SRV records abfragen, die IP-Adressen auflösen, sich zu dem port verbinden, StartTLS und direktes TLS testen. Auch die Gültigkeit der Zertifikate wird geprüft.

Ich hoffe, dass das tool nicht nur für mich, sondern auch für andere Serverbetreiber nützlich ist.

Da ich einen XMPP server betreibe muss ich manchmal Probleme mit s2s (server zu server Kommunikation) debuggen. Dazu gehört es auch, zu prüfen ob die SRV records im DNS richtig gesetzt sind und ob ein XMPP server auf diesen ports lauscht.

Da mir das Prüfen der SRV records mit dig und host und das Prüfen der Verbindung mit testssl.sh zu umständlich war habe ich mir ein kleines tool geschrieben: xmpp-dns.

Mit xmpp-dns kann man einfach die SRV records abfragen, die IP-Adressen auflösen, sich zu dem port verbinden, StartTLS und direktes TLS testen. Auch die Gültigkeit der Zertifikate wird geprüft.

Ich hoffe, dass das tool nicht nur für mich, sondern auch für andere Serverbetreiber nützlich ist.

Die MZLA Technologies Corporation hat mit Thunderbird 78.14 und Thunderbird 91.1 planmäßige Updates für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 78.14

Mit dem Update auf Thunderbird 78.14 hat die MZLA Technologies Corporation ein planmäßiges Update für seinen Open Source E-Mail-Client veröffentlicht und behebt damit aktuelle Sicherheitslücken.

Neuerungen von Thunderbird 91.1

Sicherheitslücken behebt ebenso Thunderbird 91.1. Darüber hinaus bringt das Update diverse Fehlerbehebungen der Versionsreihe 91, welche sich in den Release Notes (engl.) nachlesen lassen.

Der Beitrag Thunderbird 78.14 und Thunderbird 91.1 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Mi, 8. September 2021, Ralf Hersel

Tails 4.22 macht den neuen Tor-Verbindungsassistenten, der mit Tails 4.20 eingeführt wurde, leistungsfähiger, indem die Schnittstelle für benutzerdefinierte Brücken so geändert wurde, dass nur noch die Eingabe einer Brücke möglich ist, eine benutzerdefinierte Brücke im Persistent Storage gespeichert werden kann und Tor Verbindungen, die Brücken verwenden, stabiler werden, indem Benutzer die Uhr manuell einstellen können.

Ausserdem wurde die Zeitüberschreitung, die bestimmt, ob eine Tor-Verbindung aufgebaut werden kann, von 30 auf 10 Sekunden reduziert, die Zeitüberschreitung zum Starten von Tor von 120 auf 600 Sekunden erhöht, was den Tor-Verbindungsassistenten bei langsamen Internetverbindungen stabiler macht, und es erlaubt den Nutzern nun, vom Fehlerbildschirm aus erneut zu versuchen, sich mit Tor zu verbinden.

Zudem behebt Tails 4.22 ein Problem, das auftrat, wenn man sich über die Standardbrücken mit Tor verband und die Wi-Fi-Einstellungen im persistenten Speicher gespeichert wurden, und versucht nicht mehr, sich im Hintergrund mit Tor zu verbinden, wenn der neue Tor-Verbindungsassistent den Fehlerbildschirm erreicht. Der unsichere Browser von Tails wurde in dieser Version auch verbessert, indem Tor nicht mehr neu gestartet wird, wenn der unsichere Browser verlassen wird und der persistente Speicher nur noch in der Warnung des unsicheren Browsers erwähnt wird, wenn persistenter Speicher verfügbar ist.

Neben anderen Änderungen lädt Tails nun immer automatische Upgrades von einem funktionierenden Mirror herunter, bietet bessere Unterstützung für AMD-Grafikkarten durch die Aktualisierung der AMD-Grafik-Firmware auf Version 20210818 und fügt Russisch zur Offline-Dokumentation hinzu. Unter der Haube wird Tails 4.22 weiterhin vom LTS-Kernel 5.10 angetrieben und nutzt die Software-Repositories von Debian 10 "Buster". In dieser Veröffentlichung sind der anonyme Webbrowser Tor Browser 10.5.6 und der E-Mail-Client Mozilla Thunderbird 78.13 enthalten.

Weitere Details stehen in den Release Notes:

Quelle: https://tails.boum.org/news/version_4.22/index.en.html

Mi, 8. September 2021, Marco

Am Montag wurde die Version 123 der debianbasierten Distribution Finnix veröffentlicht. Finnix ist eine kleine Linuxdistribution, welche von einer CD gestartet werden kann. Die Hauptzielgruppe von Finnix sind Systemadministratoren, welche Festplatten mounten und manipulieren, Netzwerke überwachen oder Boot records neu bauen müssen respektive möchten. Neben den vorgestellten Zwecken kann die Distribution auch für weitere Tätigkeiten verwendet werden.

In der aktuellsten Version wurden unterschiedliche Neuerungen vorgenommen und Fehler behoben. So gibt es neu die Kerneloptionen sshd und passwd. Ab dieser Version sollte die Rechner-ID auch über Reboots hinweg gleich bleiben. Dies ist beispielsweise bei der Konfiguration der IP-Adresse über DHCP ein erheblicher Vorteil. Neu beherrscht das Kommando finnix Bedienungshinweise für das ZFS-Dateisystem. Ab der Version 123 wird bei Befehlen, welche nicht gefunden werden konnten, ein Hinweis zum womöglich gemeinten Paket geliefert und Anweisungen zur Installation bereitgestellt. Das Team hinter Finnix spendierte einigen Finnix-eigenen Befehlen wie zum Beispiel wifi-connect oder locale-config eine Manpage. Neu sind die Pakete ftp, ftp-ssl und zile nicht mehr verfügbar. Dafür wurde der Emacs-ähnliche Editor jove hinzugefügt.

Neben diesen Neuerungen wurden in dieser Version auch einige Pakete aktualisiert. Normalerweise nutzt die Distribution den Testing-Zweig von Debian. Da der Release von Debian 11 allerdings erst vor Kurzem war, haben sich die Entwickler entschieden, direkt den stabilen Zweig von Debian 11 zu verwenden. Weitere Informationen, die ISO-Dateien sowie die GPG-Signaturen finden sich in den Release Notes.

Quelle: https://www.finnix.org/Finnix_123_release_notes

Mozilla hat Firefox 92 für Windows, Apple macOS und Linux veröffentlicht. Dieser Artikel fasst die wichtigsten Neuerungen zusammen – wie immer auf diesem Blog weit ausführlicher als auf anderen Websites.

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

Firefox 92 bringt Detail-Verbesserungen

Verglichen mit den vorherigen Veröffentlichungen ist Firefox 92 ein unauffälliges Update, welches vor allem Detail-Verbesserungen statt große neue Features bringt.

So gehört es schon fast zu den auffälligsten Neuerungen von Firefox 92, dass die Fehlerseite für Netzwerkfehler optisch überarbeitet worden ist und ohne grellen gelben Rand nun angenehmer zu betrachten ist.

Optisch überarbeitet wurde auch die Ansicht von Ordnern in der Lesezeichen-Symbolleiste. Diese folgen nun dem Design der anderen Menüs in Firefox seit Version 89. Auch der Dialog zum Löschen der neuesten Chronik folgt jetzt dem mit Firefox 89 eingeführten Proton-Design.

Nutzer von Apple macOS erreichen die Teilen-Funktion jetzt auch über das Datei-Menü in der Menüleiste.

Verbesserungen der JavaScript-Speicherverwaltung sollen deren Performance und Speicherverbrauch verbessern. Auch die Performance mit Screenreadern und anderen Barrierefreiheits-Werkzeugen wurde verbessert und soll nicht mehr so stark beeinträchtigt werden, wenn Thunderbird nach Firefox installiert oder aktualisiert worden ist. Außerdem verursacht ein offener alert-Dialog nicht länger Performance-Probleme in anderen Tabs, welche den gleichen Prozess nutzen. Ebenfalls verbessert wurde die Performance mit geöffneten Entwicklerwerkzeugen.

Auch die Privatsphäre wurde weiter verbessert: Die Geolocation-API erlaubt keine Standort-Updates mehr, wenn der entsprechende Tab im Hintergrund ist.

Der SmartBlock-Mechanismus, welcher Scripts bekannter Tracking-Dienste durch eine Art Ersatz-Script ersetzt, welches sicherstellt, dass die Website-Kompatibilität nicht beeinträchtigt wird, wurde um Ersatz-Scripts für Optimizely und Ads By Google ergänzt.

Firefox kann Verbindungen jetzt automatisch auf HTTPS upgraden, indem HTTPS RR als Alt-Svc-Header verwendet wird.

Für die Wiedergabe von Videos werden nun auf vielen Systemen Vollbereichsfarbstufen unterstützt. Unter Apple macOS wurde die Unterstützung von Bildern mit ICC v4-Profil aktiviert.

Die Neuimplementierung des Local Storages, an welcher Mozilla bereits seit längerer Zeit arbeitete, wurde in Firefox 92 standardmäßig aktiviert.

Auf Webstandard-Seite erwähnenswert ist die Unterstützung der CSS-Eigenschaft accent-color. Die Eigenschaft font-family unterstützt jetzt system-ui als Wert. Diverse Verbesserungen gab es auch für die WebExtension-Schnittstelle für Downloads.

Eine Übersicht über alle Verbesserungen der Webplattform wie neue unterstützte Webstandards gibt es wie immer in den MDN web docs.

Natürlich kamen auch in Firefox 92 Fehlerbehebungen und sonstige Verbesserungen unter der Haube dazu.

Geschlossene Sicherheitslücken

Auch in Firefox 92 wurden wieder mehrere Sicherheitslücken geschlossen. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 92 daher für alle Nutzer dringend empfohlen.

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

OpenSSL ist eine Softwarebibliothek, die Implementierungen für bestimmte kryptographische Verfahren, die besonders in der Netzwerkkommunikation eingesetzt werden, bereitstellt. Heute wurde Version 3.0 veröffentlicht.

Neue Versionierung

Anwender und Entwickler, die bereits mit OpenSSL arbeiten, werden mitunter erschrocken sich fragen, warum dieser Versionssprung stattfindet – so war zuletzt Version 1.1.1l aktuell und OpenSSL für eine sehr zurückhaltende Numerierung bekannt.

OpenSSL steigt nun allerdings, wie bereits 2018 angekündigt, auf die Semantische Versionierung um, welche ein klares Schema vorgibt, welche Änderungen zu welcher Anhebung der Versionsnummer führen. Dabei liegt der Dreh- und Angelpunkt bei der API: wird die erste Versionsnummer (Major) erhöht, gibt es Änderungen an der API, die nicht abwärtskompatibel sind. Ergänzungen erhöhen die Versionnummer hinter dem ersten Punkt und Patches die nach dem zweiten Punkt. Ein Sprung von 1.1.1 auf 3.0 steht also für nicht abwärtskompatible API-Änderungen, weswegen alle, die auf OpenSSL setzen, einen Blick auf die Neuerungen werfen sollten, die wir uns gleich anschauen werden. Die Versionnummer 2.0 wurde im Übrigen übersprungen, da teilweise das FIPS-Modul schon auf die Weise numeriert wurde.

Änderungen

Folgende Änderungen fallen im Changelog auf:

• Mit Version 3.0 wird ein neues Konzept zur Modularisierung eingeführt: die Provider. Sie ersetzen die ENGINE API sowie dessen Implementierungen und sollen die Wartbarkeit der Implementierungen erhöhen. Algorithmen können nun flexibel eingeführt werden, solange es eine API gibt, die den entsprechenden Typen unterstützt. Das Kontext wird in der entsprechenden Man-Page ausführlich erklärt. Die Algorithm Types heißen nun Operationen (operations).

• Weiterhin soll vor allem aufgeräumt werden. Dafür wurden viele API-Funktionen als veraltet deklariert, darunter TLS_MAX_VERSION, DTLS_MAX_VERSION, DTLS_MIN_VERSION und viele Low-Level-Funktionen.

• Ein Byte-Order-Mark am Anfang von PEM-formatierten Dateien wird nun ignoriert.

• Die Validierung der Operationsparameter kann nun solange verzögert werden, bis die eigentliche Operation stattfindet, da die Implementierungen der kryptographischen Operationen in die Provider verschoben wurde. Somit lässt sich das Verhalten und die Fehlerbehandlung verändern. Als Beispiel wird angeführt, dass der Funktionsaufruf einer nicht unterstützen Kurve mit EVP_PKEY_CTX_set_ec_paramgen_curve_nid() nicht fehlschlagen wird, wohl aber Funktionen zur Schlüsselgenerierung mit EVP_PKEY_CTX.

• ERR_GET_FUNC() wurde vollständig entfernt.

• Datumsangaben können nun gemäß ISO 8601 formatiert werden. Dies ist allerdings keine Standardeinstellung.

• Weiterhin gibt es Änderungen bei den Funktionssignaturen. So wechseln die Signaturen der Funktionen zum Setzen oder Ausgebnen von Optionen für SSL und SSL_CTX von unsigned long auf uint64_t. Somit kann sichergestellt werden, dass die Datentypen auf allen Systemen exakt 64 Bit lang sind statt der bisherigen Anforderung auf mindestens 32 Bit. Nebenbei entspricht ein uint64_t einem long long.

• Clientseitig initiierte Renegotiations sind nun standardmäßig deaktiviert und können mit z. B. -client_renegotiation oder SSL_OP_ALLOW_CLIENT_RENEGOTIATION wieder aktiviert werden.

• abspath- und includedir-Pragmas werden im Code verwendet, um Sicherheitsrisiken durch relative Inkludierung aus dem Weg zu gehen.

• Die APIs für PKCS#12-Dateien, die oft eingesetzt werden, um Private Key und Zertifikat in einer Datei zu speichern, wurden so erweitert, dass sie nun einen Bibliothekskontext akzeptieren. pkcs12 selber nutzt nun PBKDF2, AES und SHA-256 mit einem MAC-Iterationszähler gemäß PKCS12_DEFAULT_ITER. openssl pkcs12 gibt überdies nun alle PKCS#12-Attribute und nicht mehr nur das erste aus.

• Linux' Kernel TLS wird nun unterstützt.

• Ausgaben verschiedener Kommandos wurden leicht angepasst.

• openssl speed greift nun nicht mehr auf Low-Level-APIs zurück.

• Die verfügbaren Provider können nun per openssl list -providers angezeigt werden.

• CMP und CRMF gemäß RFC 4210, 4211 und 6712 wurden hinzugefügt.

• DH Modulos müssen nun mindestens 512 Bits lang sein.

• FFDHE Key Exchange in TLS 1.3 wird nun unterstützt.

Der Fokus lag bei diesem Release besonders beim FIPS-Modul. Darüber hinaus strebt OpenSSL eine Zertifizierung nach FIPS 140-2 an, weswegen einige Änderungen Anpassungen an Standards enthalten. So wird z. B. nicht mehr möglich sein, mehr als 2⁶⁴ TLS Records in einem Zug mit AES-GCM zu verschlüsseln, um die Einzigartigkeit von Schlüssel und Intialisierungsvektor (IV) zu gewährleisten. PBKDF2 orientiert sich überdies nun an SP800-132 statt an PKCS#5 RFC 2898.

Diese zahlreichen Änderungen machen mitunter eine Migrationen bei allen OpenSSL-einsetzenden Programmen notwendig. Die OpenSSL-Entwickler stellen hierfür eine entsprechende Migrationsanleitung bereit.

Neue Lizenz

Zu guter Letzt gibt es Anpassungen bei der Lizenz. OpenSSL 3.0 steht unter der Apache License 2.0. Somit gilt nun nicht mehr die angepasste BSD-Lizenz, die eine Werbeklausel enthält. Die Umstellung wurde bereits vor vier Jahren anvisiert.

Kurzeinordnung

Es freut mich, dass sich einiges beim OpenSSL-Projekt tut. Die Liste der Änderungen ist lang, es wird viel bereinigt. Allerdings bleibt in meinen Augen die Sorge, dass dieser große Release langsamer als sonst seinen Weg in die Endprodukte findet. OpenSSL wird in allen möglichen Systemen auch fernab von klassischen Computersystemen eingesetzt und stellt somit das Rückgrat sicherer Netzwerkkommunikation dar. Die Umstellung der Versionierung sorgt nicht nur für kurze Verwirrung, sondern sollte auch im Hinterkopf behalten werden, wenn Versionsprüfungen fehlschlagen: sie könnten so programmiert sein, dass sie nur den Major-Release überprüfen - dabei sollte der überwiegende Teil der Software, die bereits mit 1.1.1l lief, auch mit OpenSSL 3.0 laufen.