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.

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.

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

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:

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) und bin somit vollständig unabhängig von der Desktopumgebung. Eventuell stelle ich hier doch noch irgendwann auf Deja-Dup um, aber das ist noch nicht entschieden.

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.

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.

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.

Windows ist der Standard, Linux und macOS die Alternativen. Selbst die meisten wechselwilligen Anwender haben fest gefügte Arbeitsabläufe und Anforderungen. Die Supportforen und Kommentarspalten sind voll davon, wie man auf solche Anforderungen nicht reagiert.

In der Regel handelt es sich um wechselwillige Anwender, manchmal sind diese Nutzer auch schon gewechselt und wollen nun ihren Workflow von Virtuellen Maschinen mit Windows oder Krücken wie Wine hin zu nativen Programmen umstellten oder aber native Programme werden eingestellt und sie suchen Alternativen. Entweder fragt man im Familien-, Freundes- und Bekanntenkreis oder schlägt auf einer der zahllosen Plattformen im Internet auf.

Dort wimmelt es dann von Beispielen, wie man auf solche Anfragen nicht reagiert:

• Die Anforderung wird disqualifiziert, weil sie nicht der „Unix-Philosphie“ entspricht, die doch behauptet „Schreibe Computerprogramme so, dass sie nur eine Aufgabe erledigen und diese gut machen“. Dabei ist es unerheblich, dass die Vertreter dieses Unix-Philosophie-Arguments in der Regel keinen blassen Schimmer von Unix-Philosophie haben und wie alle Fanatiker überhaupt nicht kontextualisieren.
• Die Anforderung wird disqualifiziert, weil der Anwender es schon immer falsch gemacht hat. Beispiel: So etwas macht man doch nicht mit einem Tabellenkalkulationsprogramm, dafür gibt es richtige Datenbanksysteme oder: Für so etwas nimmt man doch nicht Word, Profis arbeiten mit LaTeX.
• Die Anforderung wird disqualifiziert, weil man den Anforderungsfall negiert. Beispiel: Das Dateiformat PDF ist nicht zum bearbeiten da. Dafür gibt es andere Formate. Du brauchst kein PDF-Bearbeitungsprogramm.
• Die Anforderung ist legitim, eine Lösung von der Stange gibt es nicht: Beispiel: Das ist ein Problem, ich habe mir dazu eine Reihe von Skripten geschrieben, aber die sind schlecht dokumentiert und die kannst du nicht verwenden. Aber du kannst ja eben schnell selbst lernen solche Skripte zu schreiben.
• Die Anforderung passt nicht zur Projekt-Philosophie, deshalb erklärt man sie für unsinnig. Beispiel: Dateien und Ordner auf dem Desktop. Wollen viele Leute haben, bieten Windows und macOS an. Desktopentwickler bei Linux haben sie zeitweilig (KDE) oder dauerhaft (GNOME) für überflüssig erklärt und die Claqueure unter den Anwendern sekundieren fleißig, indem sie allen die das fordern bzw. wünschen schlechte Dateiorganisation unterstellen.
• Die Anforderung lässt sich mit Linux nicht umsetzen, deshalb erklärt man sie für veraltet/unsicher/was-auch-immer. Beispiel: Offline-Synchronisation zwischen Desktop und Smartphone ist doch total veraltet, das macht man inzwischen über die Cloud. Wenn du Bedenken wegen der Privatsphäre hast, setze dir doch eine Nextcloud auf einem Server auf. Wie du hast keinen Server?

Diese Liste ließe sich sicher noch um einiges verlängern. Stattdessen sollte man jeden Anwendungsfall erst mal legitim finden und analysieren.

Diese Analyse kann durchaus mal das Ergebnis haben, dass der Anwendungsfall Quatsch ist. Ich hatte beispielsweise mal einen Fall, wo bemängelt wurde, dass Taschenrechner und Tabellenkalkulation ständig den Fokus beim scrollen verlieren. Dem Anwender war nicht klar, dass jedes Tabellenkalkulationsprogramm selbst rechnen kann. Das zeigt man ein mal und dann ist das ursprüngliche Problem mit einem Schlag wirklich unwichtig.

Andere Probleme könnten sich durch ein alternatives Protokoll lösen lassen. Manche Anwender schlagen z. B. mit komplexen Synchronisationslösungen für Mails auf, weil sie immer noch POP3 anstelle von IMAP verwenden. Hier hilft manchmal einfach die Anwender in die richtige Richtung zu schupsen. Was nicht unbedingt bedeutet, dass im Einzelfall nicht dennoch POP3 die bessere Wahl bleiben könnte. Hier sollte man immer ergebnisoffen bleiben.

Meistens sind die Anwendungsfälle aber komplexer. Manchmal muss man etwas machen, was das Format nicht vorsieht, aber unter Systemen wie Windows möglich ist. Mein gegenwärtiges Lieblingsbeispiel ist das, was in Bibliotheken der sogenannte Konstanzer Workflow oder Konstanzer Methode genannt wird. Dabei geht es – ganz stark verkürzt – um eine Vorgehensweise, wie man die Verlagsversion von Aufsätzen (das sind PDFs) so bearbeitet, dass man sie über das institutionelle Repositorium zweitveröffentlichen kann, ohne die Policies und gesetzlichen Anforderungen zu verletzen. Das geht nur mit ausgefeilter PDF-Bearbeitung, einem PDF-Drucker (kein speichern) und einer Bearbeitung der Metadaten. Das ist total sinnlos, aber über manche Dinge kann man nicht streiten. Man sollte sie auch nicht pauschal disqualifizieren.

Ganz hilfreich ist der Typus des Besserwissers, der stark veraltetes Wissen oder stark selektives Wissen hat, aber das nicht eingestehen möchte. Ich nenne ihn immer gerne den „LaTeX-Typus“. Standardherangehensweise ist alle Anfragen zu LibreOffice oder MS Office, Scribus etc. pp. mit LaTeX zu kontern. Gerne in folgendem Argumentationsstil: Alle Wissenschaftler arbeiten mit LaTeX, weil nur LaTeX für die Langzeitarchivierung geeignet ist und alle Verlage gerne LaTeX akzeptieren. Jede Entwicklung neben LaTeX ist unbedeutend, der Fragesteller ist nur so faul die steile LaTeX-Lernkurve zu absolvieren. Das ist selektiv bis falsch und der Wissensstand von circa 2005-2010, aber dem Besserwisser ist das egal, weil seine Wissen vermeintlich überlegen ist.

Besonders fatal sind jene Kommentatoren (Hilfesteller mag ich sie nicht nennen, weil sie nicht helfen), die sich derart in ihr System eingeigelt haben, dass sie gar nicht wissen, was andere Systeme können und auf jedweden Verweis mit „Brauch ich nicht“ und „Brauchst du auch nicht“ reagieren.

Nur mal als Denkanstoß, nachdem ich heute morgen bei der Suche nach einer Lösung wieder in sehr vielen Supportforen in den Abgrund schauen durfte.

Der Artikel Wie man nicht auf Nutzer-Anforderungen reagieren sollte erschien zuerst auf [Mer]Curius

Synology bietet tolle NAS Systeme. Leider wird das Betriebssystem DiskStation Manager (DSM) mit älteren Versionen ausgeliefert. Updates kamen in der Vergangenheit schon selten. Ein dokumentiertes Problem mit OpenSSL zeigt aber erneut, wie fahrlässig Synology agiert.

In OpenSSL wurde vor gut 2 Wochen eine Lücke geschlossen (CVE-2021-3711). Die Lücke hat ein hohes Risiko und kann aus der Ferne ausgenutzt werden. Die bekannten Hersteller von NAS Systemen QNAP und Synology mussten ein paar Tage später einräumen, dass ihre Betriebssysteme von dem Problem betroffen sind.

Bei beiden Systemen handelt es sich um Serverbetriebssysteme, die vom Hersteller durchaus so ausgelegt sind, dass sie direkt aus dem Netz zu erreichen sind. Der einzelne Anwender kann sich natürlich trotzdem entscheiden das NAS nur im Heimnetz zu betreiben oder lediglich per VPN auf die Dienste zuzugreifen, aber man getrost davon ausgehen, dass viele Kunden direkt mit Port-Forwarding agieren.

Stand heute hat Synology für sein aktuelles Betriebssysteme DiskStation Manager 7 immer noch kein Update bereitgestellt. Es ist ein RC-Kandidat für ein Update verfügbar, aber aus dem Changelog geht nicht klar hervor, ob dieses Update auch besagte Lücke schließen soll. Aufgrund der stark verzögerten Roll-out Richtlinie von Synology bekommen die meisten Anwender das Update wohl erst in einigen Wochen.

Bei mir hört langsam das Verständnis für Synology auf. Der DiskStationManager ist letztlich nur eine Linux-Distribution. Bis auf einige eigene Lösungen baut man auf viel Vorarbeit der Community auf. Es ist mitnichten so, dass hier selbst Fehleranalyse betrieben und ein Update entwickelt werden musste, denn OpenSSL hat upstream das Problem behoben. Synology bekommt es nur nicht hin, dieses Update zeitnah für seine DSM auszurollen.

Das ist umso unverständlicher, als Synology, ähnlich wie z. B. Apple, den DSM nur für eine stark begrenzte Anzahl an Systemen anbietet und aktuell lediglich zwei supportete Varianten des DSM anbietet. Die aktuelle Version DSM 7 und die ältere DSM 6.2. Hier müssen nicht hunderte unterschiedliche Einsatzszenarien getestet werden, wie das bei allgemeiner ausgerichteten Linux-Distributionen der Fall ist.

Es drängt sich immer mehr der Eindruck auf, dass bei Synology die Entwicklung im übertragenen Sinne von drei Studenten im Keller gemacht wird, während in der Marketing-Abteilung der Champagner fließt.

Nachtrag vom 28.09.2021

Das notwendige Update 7.0.1-42218 ist nun endlich da. Die lange Dauer unterstreicht aber noch mal die Aussage aus dem Artikel.

Der Artikel Synologys fraglicher Umgang mit der Sicherheit erschien zuerst auf [Mer]Curius

Gestern gab es nach langem Warten wieder ein Update für Fedy.
Bei diesem Update haben wir einige Fehler behoben und neue Software mit aufgenommen. Somit wurde Folgendes neu mit aufgenommen:

• 1Password
• Blanket
• DBeaver
• Gitfiend
• Insync
• Mailspring

Zusätzlich dazu haben wir die Software um weitere Themes erweitert:

• Qogir Icon Theme
• Qgoir GTK Theme

Die neuste Version ist bereits seit gestern in der Fedora Copr vorhanden und in der Readme von Github ist erläutert wir ihr Fedy installieren könnt.

Viele Linux-Nutzer, selbst die enthusiastischen Vertreter, kommen nicht um Windows herum. Weil Windows bei vielen Menschen immer noch den Arbeitsalltag prägt. Ein gern verschwiegener Bestandteil unseres Alltags.

Momentan schreiben viele Anwender tolle Gastartikel zu ihrer Reise zu Linux auf Linuxnews. Ein Bereich wird zwar ab und an am Rande gestriffen, aber sonst ignoriert. Die Arbeitswelt. Denn die Reise zu Linux ist bei den meisten eine unvollständige Reise. Vorausgesetzt, man hat einen Beruf, bei dem man mit Computern arbeiten darf/muss.

Windows prägt die Büros bis in die Gegenwart. Rational betrachtet, verbringe ich mehr Zeit vor einem Windows-Rechner als vor meinen Linux-Geräten, denn die Arbeitszeit von 41 Stunden pro Woche ist eine überwiegende Windows-Arbeitszeit. Die gleiche Zeit sitze ich (zum Glück) nicht nach Feierabend und am Wochenende vor einem Linux-System.

Wenn ich hier über Linux schreibe, dann schreibe ich vor allem über Linux im Privateinsatz (plus die noch nicht fertiggestellte Dissertation). Ein Privateinsatz, der zwar über das obligatorische surfen, mailen und Videos abspielen hinaus geht, aber ein Privateinsatz bleibt.

Dabei ist es nicht mal so, dass ich Windows für die Arbeit nutzen möchte. Mein Arbeitgeber stellt mir zwar ein Notebook, dessen Betriebssystem ich nicht auswählen kann, aber – Corona machts möglich – zumindest gegenwärtig dürfte ich auch mit meinem Privatgerät arbeiten. Die IT-Abteilung supportet zwar offiziell kein Linux, hat aber am Beginn der Pandemie einige Anleitungen für VPN & Co mit Linux erstellt.

Nur möchte ich das gar nicht. Ich arbeite gerne mit Windows.

Das liegt weniger an Windows 10, das ich für ein höchst bescheidenes System halte, sondern an den Programmen. Allerdings bereits hier mit Einschränkungen, denn DirectAccess ist eine sehr anwenderfreundliche Lösung, die den Arbeitskomfort im Homeoffice gegenüber klassischem VPN deutlich erhöht. Das Gleiche gilt für die Softwareverteilung über den Endpoint-Manager und die praktischen Admin-Kennwörter mit zeitlich beschränkter Gültigkeit, wodurch die IT mit als einfachem Anwender ab und an mal Admin-Rechte geben kann. Ob Linux hier gleichwertige Lösungen bietet? Keine Ahnung!

Spätestens bei den Programmen möchte ich aber gar nicht auf Windows verzichten. Meine komplette Arbeitsorganisation erfolgt über die obligatorische Microsoft Exchange & Outlook-Kombination. Mir ist keine freie Lösung bekannt, die sich so gut zur Terminverwaltung im Team eignet. Die Mail-Funktion ist da ja eher Beiwerk.

Hinzu kommen Word, Excel und Powerpoint. Hier gäbe es freie Pendants, aber die Zusammenarbeit ist nicht sattelfest. Ich möchte nicht derjenige sein, der die umfassenden Pivot-Abrechnungstabellen zerschießt, die eine Kollegin mit vielen Arbeitsstunden und viel Excel-Expertise mühevoll erstellt hat. Mal abgesehen davon, dass LibreOffice einfach keinen Spaß macht. Eine kleine Anekdote dazu: Als kürzlich eine knappe Präsentation erstellt werden sollte, fing eine Kollegin, die sonst privat nur mit LibreOffice arbeitet, an sich richtig in das Projekt rein zu knien. Sie war einfach so fasziniert davon, wie viel Spaß es machen kann, mit Powerpoint zu arbeiten, wo Impress einfach nur eine Qual ist. Und von Access schreibe ich da noch gar nicht.

Für meinen Arbeitsworkflow ist Citavi zudem ziemlich wichtig. Das ist problematisch und ich sollte dringend mal Alternativen evaluieren. Zotero hat ja einige Sprünge gemacht aber vielleicht wird es auch EndNote. Die Migration ist aber so aufwändig, das ich davor zurückscheue. Dank Windows habe ich hier ja auch die volle Auswahl.

Ein perfekt funktionierendes PDF-Bearbeitungsprogramme ist für einige Dienstleistungen ebenso Pflicht. Hier habe ich Adobe Acrobat Pro und PDF XChange Editor zur Wahl. Bei Linux bliebe nur der ebenfalls proprietäre Master PDF Editor. Ob der die beiden erstgenannten Programme ersetzen könnte, habe ich bisher nicht komplett geprüft.

Bei anderen Programmen ist die Stabilität unter Windows einfach besser. Zoom gibt es auch für Linux, aber meiner Meinung nach liegen zwischen den Clients für die unterschiedlichen Plattformen Welten. Hier dürfte die geringere Verbreitung von Linux sich bei Zoom in weniger Aufmerksamkeit umsetzen.

Das bedeutet nicht, dass wir nur auf proprietäre Software setzen. Gerade mal geprüft, was ich so aktuell nutze: Firefox, Rocket.Chat, OpenVPN, Git, FileZilla, Gephi, OpenRefine, Notepad++, VLC. Ich verwende für die Arbeit sicher mehr freie als proprietäre Software. Nur gibt es diese auch für Windows, weshalb Linux mir keine Vorteile bietet. Einige dieser Programme gibt es sogar nur für Windows.

Natürlich ist Windows und Office für den Datenschutz eine Katastrophe, das ist hinlänglich bekannt. Es ist nur nicht meine Katastrophe, sondern die meines Arbeitgebers und das ist mir bis zu einem gewissen Maß egal. Vor den schlimmsten Auswüchsen schützt mich im Zweifelsfall sowieso der Personalrat. Viele Maßnahmen, die ich privat nutze, wie beispielsweise Cookie Management, Site Isolation usw. ignoriere ich im Arbeitsalltag weitestgehend. Ich bin ja schließlich sowieso nur beruflich mit dem Gerät unterwegs.

Linux ist und bleibt mein Privatsystem und hat hier macOS nach 4 Jahren Ausflug ins Apple-Lager wieder fast vollständig ersetzt. Windows war immer da und bleibt es auch. Selbst wenn ich es ändern könnte, ich würde es nicht wollen. Linux würde meinen Arbeitsalltag einfach nur komplizierter machen. Ich würde deshalb auch niemals in einer internen Evaluation Linux das Wort reden.

Möchte ich deshalb Windows auch privat nutzen? Nicht eine Sekunde! Denn es fühlt sich einfach nach Arbeit an und diese Trennung schätze ich sehr.

Der Artikel Windows – Der verschwiegene Arbeitsbegleiter erschien zuerst auf [Mer]Curius

Es gibt — wie immer — zwei Sichtweise auf das neue Debian: Die positive (»Das Glas ist halb voll«) Interpretation geht in die Richtung, dass Debian im Vergleich zum letzten Release deutlich moderner geworden ist, teilweise nahezu aktuelle Software-Versionen ausliefert, neue Funktionen bietet — und das für viel mehr Plattformen als bei jeder anderen Linux-Distribution.

Die nicht so euphorische Sichtweise (»Das Glas ist halb leer«) bedauert die im Vergleich zu Fedora oder Ubuntu nicht ganz so aktuelle Software-Ausstattung und das unverändert altmodische Erscheinungsbild des Installationsprogramms. Andererseits erfüllt der Installer seinen Zweck — und wer es gerne moderner hat, kann ja den Calamares-Installer der Live-Medien verwenden.

Neuerungen

Abseits von Versionsnummern gibt es nur wenige grundlegende Neuerungen in Debian 11:

• Unkomplizierte exFAT-Unterstützung (für große SD-Karten)

• Treiberloses Drucken/Scannen mit vielen neuen Geräten (dank IPP-over-USB sowie eSCL und WSD)

• Mit open datei kann aus dem Terminal heraus ein GUI-Programm als Hintergrundprozess geöffnet werden. open Downloads/bild.jpg startet beispielsweise den Bildbetrachter. open ist ausgesprochen praktisch und wird vor allem macOS-Umsteiger erfreuen. (Unter macOS gibt es ein entsprechendes Kommando schon seit vielen Jahren.) Intern ist open einfach ein via updates-alternatives --config open verwalteter Link auf das schon länger etablierte Script xdg-open, das die MIME-Einstellungen auswertet. (Anstelle von xdg-open kann auch run-mailcap eingestellt werden.)

• Control Groups v2: Die Kernel Control Groups zur Überwachung/Steuerung von Prozessen liegt jetzt in Version 2 vor. Das ist wichtig u.a. für Container-Systeme wie Docker oder Podman. Diese Umstellung kann allerdings Probleme mit OpenStack verursachen (Details).

• User Namespaces aktiv: Eine Neuerung von Kernel 5.10 besteht darin, dass normale Benutzer User Namespaces verwenden dürfen. Das ist wichtig für Containersysteme (Rootless Docker, Podman).

• FUSE 3: Die Dateisysteme gvfs-fuse, kio-fuse und sshfs nutzen nun FUSE 3 anstelle der bisher üblichen Version 2.

• Das von systemd stammende Logging-System Journal wird jetzt dauerhaft im Binärformat in /var/log/journal gespeichert, geht also nicht wie in früheren Debian-Versionen mit jedem Reboot verloren. (Parallel zum Journal läuft weiterhin auch der rsyslogd und erzeugt die traditionellen Text-Logging-Dateien in /var/log.)

• Passwort-Hashes in der Datei /etc/shadow wurden von SHA-512 auf das sicherere Verfahren yescrypt umgestellt.

Ärgernisse

sudo: Ein wenig irritierend ist, dass der »gewöhnliche« Installer (also nicht der der Live-Medien) nach wie vor keine Möglichkeit bietet, den neuen Benutzer zur sudo-Gruppe hinzuzufügen. Das ist mittlerweile bei fast allen anderen Distributionen das Standardverhalten.

Abhilfe: Führen Sie mit root-Rechten usermod -a -G sudo <accountname> aus, um sudo für den betreffenden Account zu aktivieren.

Bitte legen Sie das Medium mit dem Namen ‚Debian GNU/Linux‘ ein: Der Standardinstaller hinterlässt in /etc/apt/sources.list eine Zeile mit dem Installationsmedium (USB-Stick oder DVD). Wenn Sie nach der Installation ein Paket installieren wollen (apt install <name>), will apt, dass Sie das Installationsmedium wieder einlegen, anstatt das betreffende Paket einfach herunterzuladen. Das ist (schon seit vielen Jahren) nicht mehr zeitgemäß.

Abhilfe: Öffnen Sie /etc/apt/sources.list mit einem Editor und entfernen Sie die Zeile, die mit deb cdrom beginnt.

Cannot set locale en_US.utf-8: Wie aktuell bei diversen anderen Distributionen tritt auch bei Debian ein Problem mit den Lokalisierungseinstellungen ein, wenn während der Installation die deutsche Sprache voreingestellt wird. Nach einem SSH-Login jammert Debian: bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf-8). Es wurde also die deutsche Lokalisierung installiert, nicht aber die englische (die als Backup immer zur Verfügung stehen sollte).

Abhilfe: Führen Sie mit root-Rechten dpkg-reconfigure locales aus und aktivieren Sie zusätzlich zur schon voreingestellten Lokalisierung auch en_US.utf-8.

Versionsnummern

Basis             Desktop             Programmierung   Server
---------------   ------------------  --------------   --------------
Kernel     5.10   Gnome        3.38   bash       5.1   Apache     2.4
glibc      2.31   Firefox ESR    78   docker   20.10   CUPS       2.3
X-Server   1.20   Gimp         2.10   gcc       10.2   MariaDB   10.5
Wayland    1.20   LibreOffice   7.0   Java     11/17   OpenSSH    8.4
Mesa       20.3   Thunderbird    78   PHP        7.4   qemu/KVM?  5.2
Systemd     247                       Python     3.9   Postfix    3.5
NetworkMan 1.30                                        Samba     4.13
GRUB       2.04 

Der Linux-Kernel ist zwar nicht ganz aktuell, dafür genießt er aber Langzeitunterstützung durch das Kernel-Entwickler-Team.

Die Unterstützung von Java 17 ist insofern bemerkenswert, als die kommende LTS-Version von Java noch gar nicht fertig ist. Indem schon jetzt Pakete mitgeliefert werden, können später (vorauss. im Okt. oder Nov. 2021) unkompliziert Updates installiert werden. Als »offizielle« Java-Version von Bullseye gilt aber Java 11. Die Release Notes weisen darauf hin, dass es für Java 17 voraussichtlich keine quartalsmäßigen Updates geben wird (was schade ist).

Plattformen (Architekturen)

Debian 11 steht für die folgenden Plattformen zur Verfügung:

• Standard-PCs: i386 und amd64
• ARM: arm64, armhf, armel
• MIPS: mipsel, mips64el
• PowerPC: ppc64el
• S390X: s390x

Weitere Details zur Hardware-Unterstützung können Sie hier nachlesen:

• Unterstützte Architekturen
• Ports

Fazit

Debian hat einmal mehr ein grundsolides Release geliefert. Sensationen bleiben aus, Glanz und Charme versprüht die Distribution auch nicht. Dafür läuft Debian zuverlässig und stabil und bildet direkt (Ubuntu, Raspberry Pi OS) oder indirekt (Ubuntu Derivate) die Basis für zahlreiche weitere Distributionen. Insofern macht Debian — ohne über ein Budget wie Canonical, IBM/Red Hat oder SUSE zu verfügen — alles richtig. Wer mehr Aktualität sucht, kann den Testing-Zweig verwenden.

Quellen und Testberichte

• Release Notes
• Installationsanleitung
• Test von heise.de
• Test von golem.de
• Distrowatch

Download-Links (jeweils für AMD/Intel 64 Bit)

• Standard-ISO-Image (DVD-1 reicht)
• ISO-Image plus Firmware (empfehlenswert, enthält zusätzlich zum Standard-Image nicht-freie Firmware-Dateien für WLAN-Adapter & Co.)
• Live-Image (Live-Image mit Calamares-Installer)
• Live-Image plus Firmware

Leap ist der stabile Zweig von openSUSE mit LTS-Support. Mit Version 15.3 aus dem Frühjahr 2021 handelt es sich dabei faktisch um SUSE Linux Enterprise mit einigen Zusatzpaketen. Anfangs gab es allerdings Probleme mit der Qualität.

Kurzfristig zum Release eingeführte Änderungen an den Update-Repositorien führten zu einem schweren Fehler, bei dem – Unachtsamkeit oder Automatismen vorausgesetzt – das halbe System deinstalliert werden konnte.

Diese Probleme sind inzwischen behoben. Ich schreibe das so dezidiert, da mich nach dem Artikel viele Anwender kontaktiert hatten, die ähnliche Probleme hatten oder ihr System bereits durch massenhafte Deinstallation von Paketen beschädigt hatten.

Woran es genau lag, ist bis heute nicht offen kommuniziert worden. Die Kommunikation von openSUSE war in diesem Zusammenhang wirklich schwach. Das betrifft sowohl die Erklärungen im Nachhinein als auch die Warnungen, während das Problem noch bestand. Eigentlich hätte man prominent auf der Webseite warnen müssen (oder das Release kurzzeitig zurückziehen müssen), aber entweder kam niemand auf die Idee oder die Abstimmungsmechanismen für so etwas sind bei openSUSE zu behäbig.

Wie dem auch sei: Die Probleme bestehen nicht mehr und openSUSE Leap ist nun wieder stabil zurück in der Spur. Ich habe alle Systeme umgestellt und kann keine Probleme mehr berichten.

Ganz im Gegenteil, denn erst die Aufteilung der Repositorien in Updates von SLE und openSUSE macht für den Anwender transparent, wie sehr er von der Zusammenführung von openSUSE und SLE profitiert. Ohne für Enterprise-Qualität zahlen zu müssen! Lediglich ein kleiner Teil der Pakete und der Updates kommen noch vom openSUSE-Projekt.

Bei den SLE-Updates profitieren openSUSE-Anwender von der Arbeitskraft der für ihre Arbeit an SLE bezahlten SUSE-Mitarbeiter und der Enterprise-Qualität. Meiner subjektiven (!) Meinung nach werden bei SLE (und damit auch openSUSE) auch mittelschwere Fehler hartnäckiger verfolgt als beispielsweise bei Debian oder Ubuntu und nicht nur absolut sicherheitsrelevante und total kritische Probleme nach dem Release beseitigt. Zu Red Hat fehlt mir da der Vergleich.

Die Roadmap für das nächste geplante Minorrelease des 15-Zweiges openSUSE Leap 15.4 steht übrigens fest. Die Veröffentlichung ist für den 22. Juni 2022 geplant. So lange kann man nun auf jeden Fall wieder mit und nicht am System arbeiten. Mal sehen was dort und im maßgeblichen Service Pack von SLE 15 kommt. Ich spekuliere fest auf einen aktuelleren Kernel und aktuellere Versionen bei den Desktopumgebungen, aber das wird sich zeigen.

Der Artikel openSUSE Leap 15.3 wieder in der Spur erschien zuerst auf [Mer]Curius

In diesem Beitrag möchte ich meine persönliche Meinung zu und über Linux-Container mit euch teilen. Ich freue mich, wenn sich daraus eine Diskussion entwickelt, in der ihr eure Erfahrungen und Gedanken zum Thema einbringt.

Mir geht es dabei ausschließlich um Linux-Container, welche ich von ähnlichen Konzepten wie z.B. den LDOMs und Kernel-Zones unter Solaris, etc. bewusst abgrenzen möchte.

Was habe ich mit Containern zu tun?

Nun, Container haben in vielen Branchen Fuß gefasst, in denen IT/EDV eine Rolle spielt und werden voraussichtlich nicht mehr verschwinden. Ich selbst bin als Sysadmin und Nerd sowohl aus privatem Interesse, als auch beruflich mit dem Thema in Berührung gekommen.

Mit den Konzepten und der Architektur bin ich vertraut. Mit dem Wochenendprojekt „Kanboard im Container…“ verfüge ich über wenig praktische Erfahrung.

Wie lautet das Versprechen der Container-Technologie?

Alles wird agiler, schneller, effizienter, sicherer UND einfacher. Das Übliche halt.

Im Wesentlichen bieten Container die Chance, dass Anwendungen mit all ihren Abhängigkeiten ausgeliefert werden können.

Damit könnte das Ende der Zeit eingeläutet werden, wo einer Anwendung eine Installationsanleitung mit dem Kapitel „Systemvoraussetzungen“ beiliegt, mit welcher der Administrator sich auf die Suche nach den benötigten Bibliotheken und Paketen macht, welche in seiner konkreten Umgebung zu installieren und zu konfigurieren sind, bevor die eigentliche Anwendung installiert werden kann.

In der schönen neuen Welt verpacken Entwickler alles, was ihre Anwendung braucht, in einen Container, welchen sie anschließend in den Versand geben (deployen) können. Auf dem Zielsystem wird nur noch eine kompatible Container-Engine benötigt und die Anwendung läuft.

Dabei sind Szenarien realistisch, in denen Anwendungen z.B. in einem Ubuntu-Userland auf einem RHEL-Kern laufen und umgekehrt.

Auch Update-Szenarien können deutlich vereinfacht werden. Ein neues Release kommt in Form eines neuen Container-Images, welches instanziiert wird. Gibt es Probleme, bringt man die laufende Instanz um und startet eine Instanz vom vorherigen Container-Image. Vorausgesetzt die Container beinhalten keine persistent zu speichernden Daten (was sie laut Konzept nicht sollen), kann das wirklich gut funktionieren.

Und wie fühlt sich das bis jetzt in der Praxis an?

Die kurze Antwort auf diese Frage lautet: „Sehr unterschiedlich. Das Spektrum reicht von gut bis durchwachsen.“

Ich möchte noch einmal erwähnen, dass ich Systemadministrator und kein Anwendungsentwickler bin. Ich entwickle also keine Software, welche dann mit CI/CD-Pipelines verarbeitet und ausgerollt wird. Meine Aufgabe ist eher die Bereitstellung und der Betrieb von Umgebungen, in denen Container ausgeführt werden können. Zu möglichen Kunden/Nutzern zählen dabei Teams, die eigene Anwendungen entwickeln, aber auch Teams, welche Anwendungen in Form von Container-Repositorien bzw. -Images geliefert bekommen und diese dann betreiben müssen.

Insbesondere in dem Bereich, wo uns die Aufgabe des Betriebs von extern erstellten Anwendungen obliegt, machen wir gerade ein paar Erfahrungen, die ich hier gerne aus meiner persönlichen Sicht teilen möchte.

Beginnen möchte ich mit der insgesamt positiven Erfahrung, die ich mit meinem Wochenendprojekt „Kanboard im Container…“ gemacht habe. Hier laufen eine Anwendung und eine Datenbank jeweils als Container in einem Pod auf einem RHEL 8 Host mit einer Rootless-Podman-Installation und einem Reverse-Proxy. Die Dokumentation von Red Hat und dem Kanboard-Projekt sind hinreichend genau und verständlich, um diese Anwendung ohne große Mühe zu betreiben. Ohne große Verrenkungen kann ich unterschiedliche Versionen aus dem Postgres-Container-Repo ausprobieren und verschiedene Releases der Anwendungen testen.

Leider hat man nicht immer soviel Glück. Ein anderes Software-Projekt, dessen Namen ich hier bewusst nicht nenne, liefert eine kleine Sammlung von Bash-Skripten aus, welche in einer bestimmten Reihenfolge auszuführen sind, um zur Laufzeit eine Docker-Compose-Datei zu generieren, auf deren Basis dann entsprechende Container gestartet werden. Wenn nun ein Update ansteht, ist der ganze Prozess mit der Ausführung der Bash-Skripte in wohldefinierter Reihenfolge erneut durchzuturnen. Das ganze lässt sich ausschließlich auf einem Host mit einer Docker-Installation ausführen und ist zu Podman inkompatibel. Ob es auch mit einer Rootless-Docker-Installtion läuft, ist noch zu testen. Ein Deployment auf einem Kubernetes-Cluster ist undenkbar. Das Projekt stellt keinerlei Informationen dazu bereit.

Übrigens handelt es sich bei diesem Projekt nicht um ein 1-2 Personen FOSS-Projekt, sondern um eines, hinter dem ein Unternehmen steht, welches kostenpflichtige Support-Verträge für seine Anwendung vertreibt.

Es bleibt also wieder mal nur, die eigene Umgebung der Anwendung anzupassen, die sich andernfalls nur mit extrem hohen Aufwand integrieren lässt. Das kennen wir schon aus dem Zeitalter vor der Container-Erscheinung. Es ist in diesem Fall halt etwas anders, aber nicht besser.

In einem anderen Fall blieb das Erfolgserlebnis aus ähnlichen Gründen aus. Der Container mit der gewünschten Anwendung lies sich nicht in die Zielumgebung integrieren, da ein für die Kommunikation benötigtes Software-Modul fehlt. Erste Aussage des Herstellers: „Da müssen sie noch Paket XY im Container nachinstallieren.“

Halt Stopp! Sollten mit dem Container nicht alle notwendigen Abhängigkeiten mit ausgeliefert werden? Jetzt sollen wir Software im Container nachinstallieren, was zur Folge hat, dass wir damit ein neues Image erzeugen, welches wir zukünftig wieder selbst weiterpflegen dürfen? So habe ich mir die schöne neue Welt aber nicht vorgestellt. Den Aufwand mit den eigenen Anpassungen haben wir ohne Container auch. Auch hier wird es erstmal nur anders, aber nicht besser.

Allerdings möchte ich zur Ehrenrettung des Anbieters hinzufügen, dass er das fehlende Modul in sein Image einbauen und zukünftig selbst pflegen und ausliefern möchte und uns hier lediglich um Unterstützung beim Test bittet. Dies ist für mich im Sinne von FOSS und vollkommen akzeptabel. Wir wissen allerdings noch nicht, ob der Anbieter sein Versprechen hält.

Wo ist nun das Dilemma?

Ich persönlich habe eine Präferenz, wie Betriebsplattformen für Container aussehen sollten. So sehe ich die Nutzung von Rootless-Podman für einfache Anwendungen und Kubernetes bzw. Kubernetes-kompatible Lösungen für die Orchestrierung als sinnvoll an.

Leider kann ich mir nicht immer aussuchen, welche Software es zu betreiben gilt. Allzu oft muss mit dem gearbeitet werden, was bestellt bzw. geliefert wurde. Und hier sind die Probleme fast so zahlreich wie außerhalb der Container-Welt. Die einen laufen nur mit Docker, aber nicht im Rootless-Modus. Die anderen verlangen eine Docker-Swarm-Umgebung und Kubernetes mögen sie beide nicht. Das ist halt Pech.

Manchmal lassen sich die gelieferten Container auch ganz einfach starten, dafür aber überhaupt nicht in bestehende Umgebungen integrieren. So kann es schon in Arbeit ausarten, wenn man den voreingestellten Datenbank-Container herausoperieren muss, um den vorhandenen Datenbank-Cluster nutzen zu können.

Ein wenig neidisch blicke ich dabei zu Berufskollegen, die eigene Softwareentwicklung betreiben und von den Vorzügen ihrer Kubernetes-Cluster schwärmen.

Allerdings stehe ich mit meinen Erfahrungen noch ganz am Anfang und lasse mich gerne überraschen, was die Zukunft noch bringt.

Was habt ihr für Erfahrungen im Umgang und mit dem Betrieb von Containern gemacht? Könnt ihr hier Geschriebenes in Teilen nachvollziehen oder sind eure Erfahrungen völlig anderer Natur? Ich freue mich auf eure Beiträge in den Kommentaren und per E-Mail.

Bis bald im schönen neuen Container-Land.

Problem

Vor etwas weniger als einem Jahr bloggte ich bereits über mein Webcam-Setup, wo ich beschrieb, wie man eine Canon DSLR per Mini-USB unter Linux zum Laufen bringt. Das funktioniert zwar technisch, hatte aber ein paar Einschränkungen und Dinge, die mich nervten, weshalb ich das Setup wieder umgebaut habe. Hauptproblem: Das Setup braucht ein geladenes Kernel-Modul und bei jedem Anschalten der Kamera musste eine lange Befehlskette neu gestartet werden. Zudem war es nur das Preview-Bild was abgegriffen wurde. Das entsprach dann einer Auflösung von lediglich 960x640.

Hardware

Praktischer ist daher die Nutzung des HDMI-Ausgangs über ein HDMI-Capture Stick. Ich nutze dafür den Elgato Cam Link 4K. Der Stick wird direkt als Webcam identifiziert und kann ohne Probleme in jegliche Videokonferenztools genutzt werden.

Theoretisch wäre dieser Blogpost schon zu Ende. Allerdings fiel nach dem ersten Betrieb schon ein Problem auf: Über den HDMI-Ausgang wirft meine Canon 700D kein sauberes Bild aus, da dort typische Kamera Einstellungen und Darstellungen auf dem Bildschirm dargestellt werden, die auch über HDMI ausgegeben werden. Größeres Problem allerdings: Die Kamera schaltet den Live-View Modus nach 30min automatisch ab. Somit ist es nicht sonderlich gut nutzbar, dies war über USB nämlich kein Problem.

Magic Lantern

Zu dem Problem gibt es aber eine weitere Lösung: Mit Magic Lantern, eine Open Source Firmware für diverse Canon Kameras. Die Firmware wird dabei von der SD-Karte gestartet, nachdem man zuvor das passende Firmware-Update für die Kamera selbst installiert hat. Scheinbar gibt es aber für Magic Lantern selbst seit 3 Jahren keine Updates mehr. Für meinen Zweck ist das noch verkraftbar.

In den Einstellungen von Magic Lantern lassen sich dann extremst viele Konfigurationen einstellen, um mehr aus der Kamera herauszuholen zu können. In meinem Fall war ich da lediglich daran interessiert, das Auto-Abschalten des Live-Views zu deaktivieren.

Einschränkungen

Auch mit diesem Setup gibt es ein paar Einschränkungen, sonst wäre es ja langweilig. So hat das Live-View Bild im P-Modus der Kamera eine schwarzen Kasten, der auch so über HDMI ausgegeben wird. Im Automatik-Modus ist das zum Glück nicht der Fall, aber auch da hat man zumindest am linken und rechten Rand schwarze Balken, was dem Kamera-Format geschuldet ist. Dies kann man, wenn man möchte, über Software wie OBS croppen, aber das möchte ich in meinem Fall nicht.

Reguläre Webcams sind immerhin mittlerweile lieferbar zu bezahlbaren Preisen, im Gegensatz zum letzten Jahr. Ich bleibe nun erstmal bei dem Setup, alles andere wäre schließlich zu einfach (und zu günstig).

Viele Linux-Anwender haben einen gewissen missionarischen Eifer, ihre Erleuchtung in die Welt zu tragen. Doch entstehen dadurch neue mündige Linux-Anwender oder nur Abhängigkeiten?

Die ideologische Überhöhung von FOSS, die das Selbstverständnis, ein besseres System zu nutzen, das Verlangen nach dem Gang durch die Wüste nun auch andere in den Genuss der Erfahrung zu bringen – was es auch immer ist: Viele Linux-Anwender neigen dazu wie Wanderprediger um die Häuser zu ziehen und andere Anwender von dem System zu überzeugen. Deutlich mehr als Windows- oder macOS-Nutzer, die den armen Linux-Anwendern auch nicht andauernd die Segnungen ihres Systems aufdrängen möchten.

Kürzlich war ja der 30. Geburtstag von Linux und im Internet gibt es gerade zig lustige und unterhaltsame Geschichten, wie man selbst zu Linux gekommen ist. Das ist spannend, aber auch irritierend. Denn oft ergänzen Geschichten, wie man die Familie, die Oma und den Hund gleich mit gesegnet hat.

Mich würden da mal wirklich ehrliche Erfahrungen interessieren. Sind dadurch mündige Linux-Anwender entstanden oder letztlich nur von euch abhängige Netzwerke und diese kleine Linux-Nutzergemeinschaft würde in dem Moment erodieren, in dem ihr nicht mehr da seid oder vielleicht selbst das Betriebssystem wechselt?

Ich bin solchen Vorhaben, Linux anderen aufzudrängen, sehr kritisch gegenüber eingestellt. Aber vielleicht sehe ich das auch völlig falsch?

Der Artikel Was bleibt vom missionarischen Eifer? erschien zuerst auf [Mer]Curius

Es gibt viele Wege Anwendungen und Konfigurationen in einen Kubernetes Cluster zu bringen.

Der Weg ueber Helm3 gefaellt mir besonders fuer third Party Software. Man fuegt das entsprechende Repository zu Helm hinzu, passt die Variablen ueber eine Konfigurationsdatei oder Parameter an und installiert das Chart. Der Uninstall Befehl hinterlaesst den Cluster meist besenrein.

Falls Dir das Thema Kubernetes fremd ist kannst Du innerhalb von ca 5. Minuten einen MicroK9s Cluster mit diesem Tutorial installieren und meine Schritte durchgehen. Es wird ein Monitoring Stack mit Grafana und den Backends Loki + Prometheus sowie einigen Dashboards installiert und konfiguriert. Hier die Dokumentation von den Grafanalabs.

Repo hinzufuegen

# Bitte das Kommando microk8s.helm3 statt helm3 verwenden falls Du microk8s nutzt.
helm3 repo add grafana https://grafana.github.io/helm-charts
helm3 repo update

Grafana, Loki, Prometheus, Fluent.d und den Alertmanager installieren

Um eine Anwendung zu testen starte ich gerne auf der Kommandozeile und Default Parametern in den Namespace

# Namespace anlegen microk8s.kubectl statt kubectel verwenden falls Du microk8s nutzt.
kubectl create  namespace monitoring

helm upgrade --install loki grafana/loki-stack \
  --set fluent-bit.enabled=true,promtail.enabled=false,grafana.enabled=true,prometheus.enabled=true,prometheus.alertmanager.persistentVolume.enabled=false,prometheus.server.persistentVolume.enabled=false

Nach ein paar Minuten sollten alle Pods hochgefahren sein und die Anwendung verfuegbar und man kann sich ein nacktes Grafana anschauen

# Passwort besorgen 

kubectl get secret --namespace monitoring loki-grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo

# Port forwarden 
kubectl port-forward --namespace monitoring service/loki-grafana 3000:80

Jetzt solltest Du dich auf http://localhost:3000/ mit username: admin und dem Passwort aus der Commandline anmelden koennen.

Anwendung loeschen

microk8s.helm3 uninstall loki  -n monitoring

Anwendungskonfiguration als Yaml File

Cli Parametern sind pratkisch um mal etwas auszuprobieren aber bei komplexeren Einstellungen wird es schnell unuebersichtlich und eine Textdatei die man Versionieren kann ist ungemein praktischer. In ~ 50 Zeilen Yaml kann man die gleichen Einstellungen deployen mit ein paar Extras wie:

• Plugins installieren
• Admin Passwort setzen (bitte nur auf localhost so laufen lassen)
• Vorgefertigte oder selbst erstellte Dashboards installieren

values.yaml

fluent-bit:
  enabled: true
promtail:
  enabled: false
grafana:
  enabled: true
  persistence:
    enabled: false 
  adminPassword: 1q2w3e4r
  plugins:
  - grafana-piechart-panel
  dashboardProviders:
    dashboardproviders.yaml:
      apiVersion: 1
      providers:
        - name: default
          orgId: 1
          folder:
          type: file
          disableDeletion: true
          editable: false
          options:
            path: /var/lib/grafana/dashboards/default
  dashboards:
    default:
      Logging:
        gnetId: 12611
        revison: 1
        datasource: Loki
      K8health:    
        gnetId: 315
        revison: 1
        datasource: Prometheus
      ApiServer:  
        gnetId: 12006
        revison: 1
        datasource: Prometheus
prometheus:
  enabled: true
  server:
    persistentVolume:
      enabled: false
  alertmanager:
    persistentVolume:
      enabled: false

Nun den Stack erneut installieren

microk8s.helm3 upgrade --install --namespace=monitoring loki grafana/loki-stack  -f values.yaml

Analog zu den Dashboards koennen alle moeglichen und unmoeglichen Settings der Anwendung, Versionen bis zu persistant Volumes konfiguiert werden. Mir gefaellt besonders, dass wesentlich weniger Yaml produziert werden muss als z.B. bei Kustomize und man sehr schnell von „ich bastel ein wenig rum“ in den Zustand „ich habe eine wiederverwendbare Komponente die ich leicht modifizieren kann“ iterieren kann. Im naechsten Schritt kann man dann z.B. mit ArgoCD wunderbar continuous Delivery betreiben.

Der Beitrag Helm Charts verwenden erschien zuerst auf Unerklärliches am Rande.