Am 16. Oktober 2021 findet zum zweiten Mal ein reiner Online-LinuxDay AT statt.

Noch immer hat uns die Covid-Pandemie im Griff und so findet auch dieser LinuxDay wieder online statt.

Dennoch hat sich die Linux User Group Vorarlberg wieder tüchtig ins Zeug gelegt und ein abwechslungsreiches Programm mit 12 Vorträgen zusammengestellt. Informationen für Besucherinnen und Besucher stellt die LUG unter „Was wie wo – 2021“ bereit.

Ich freue mich, wenn wir uns im virtuellen Raum treffen und einen schönen LinuxDay verbringen. Hoffentlich können wir uns im nächsten Jahr wieder vor Ort treffen und ein schönes Wochenende in Dornbirn verbringen.

Viele sprechen und schreiben immer von „der“ Linux Community, aber wenn man näher hinsieht, zerfällt die Community eigentlich in zwei bzw. drei gänzlich unterschiedliche Hauptgruppen. Das sollte man berücksichtigen, wenn man über Akzeptanz und Entwicklung nachdenkt.

Das Kernproblem beim Verfassen eines solchen Artikels ist der eklatante Mangel an belastbaren Zahlen. Das liegt zum einen an Datenschutz-/Privacy-Vorbehalten, aber vermutlich wollen manche Projekte die Wahrheit gar nicht so genau wissen. Irgendjemand wird sicher in den Kommentaren sinngemäß schreiben, dass das in seinem Umfeld natürlich ganz anders sei. Aber Binnenwahrnehmungen haben selten etwas mit den realen Verhältnissen zu tun. Die AfD skandiert ja auch bei 10 % noch Wir sind das Volk, weil ihre Anhänger in ihren Blasen die Mehrheit stellen.

Einen genaueren Blick auf die Community zu nehmen ist aber sinnvoll, um interne Diskussionsprozesse besser gewichten zu können und manche Entwicklungen zu verstehen. Simplifiziert geht es um die Frage: Warum ist Ubuntu mit GNOME (und demnächst Snaps) so erfolgreich, wenn die Mehrheit der Kommentatoren in Foren und Blogs diese Konstruktion ablehnt.

Das Thema Mehrheiten, Minderheiten und die Abläufe von Diskussionsprozessen interessiert mich schon länger, weil in meiner Wahrnehmung Teile der Community das Potenzial haben, in etwas abzurutschen, was momentan gerne als „toxisches Umfeld“ beschrieben wird.

Das wiederum halte ich für fatal, weil es eine kritische Größe gibt, ab der eine Community in die Bedeutungslosigkeit abrutscht (oder dieser nie entwächst) und dann immer weniger Berücksichtigung durch Dritte gibt. BSD wäre hier ein Beispiel. Linux ist als Baustein für den Schutz der Privatsphäre oder des Datenschutzes im individuellen IT-Bereich für die „digitale Selbstverteidigung“ zu wichtig, um diese Tendenzen bedeutungslos zu finden.

Gruppe 1: Linux im Mainstream

Die erste große Gruppe sind die Masse der Anwender von Linux als Desktopsystem. Dazu hatte ich mich hier schon mal geäußert. Die Masse der Linux-Anwender verteilt sich auf ein paar wenige Distributionen und nutzt primär Software einer Handvoll Projekte.

Die große Mehrheit der Linux-Anwender nutzt Ubuntu, eines der offiziellen Derivate (Kubuntu, Xubuntu, Lubuntu usw.) oder einen der inoffiziellen Abkömmlinge (Linux Mint, elementary OS, Pop!_OS usw.). Es gibt dazu keine belastbaren Zahlen, aber Hinweise. Dazu gehören die von Canonical publizierten 25 Millionen aber auch die Größe der Communitys, die Rezeption in den Medien und die Unterstützung durch Anbieter proprietärer Programme. Ergänzend kann man sich die Ergebnisse der Steam Hardware Survey ansehen, die man aber nicht überbewerten darf, weil Gaming nur ein Segment des Linux-Desktops ist und aktuelle Treiber hier eine überproportional große Rolle spielen. Insgesamt ergibt sich ein ziemlich stimmiges Bild.

Über die internen Verteilungen möchte ich nicht ausführlich mutmaßen, aber durchaus denkbar, dass Linux Mint hier bereits vor der Stammdistribution Ubuntu liegt. Da die meisten der offiziellen und inoffiziellen Derivate direkt auf die Ubuntu LTS aufsetzen, kann man konstatieren, dass die große Mehrheit der Anwender eine LTS-Distribution nutzt. Entsprechend sind viele (proprietäre) Drittanbieter-Programme vor allem für Ubuntu LTS getestet.

Den Desktopzahlen bin ich bereits mal auf den Grund gegangen. Es gibt viel Auswahl, aber letztlich nutzt eine große Gruppe GNOME, direkt gefolgt von KDE Plasma. Danach kommen dann die kleineren Desktopumgebungen mit Marktanteilen im einstelligen oder niedrigen zweistelligen Bereich.

Installationen von Programmen nehmen diese Anwendergruppen über die von der Distribution vorgegebenen Wege vor. Das bedeutet grafische Oberflächen für Paketinstallationen und App Stores. Auf der Kommandozeile werden lediglich Dreizeiler aus dem Internet per C&P eingefügt, um ggf. PPAs für neuere Versionen einzufügen. Ob das Programm als DEB, Snap, Flatpak oder AppImage kommt, ist dieser Anwendergruppe egal – so lange es funktioniert.

Diese Community-Gruppe sollte man nicht als DAUs abstempeln oder als anspruchslose Nutzer. Mir fallen spontan gleich einige Entwickler und Systemadministratoren ein, deren Arbeitsgeräte ziemlich langweilige Ubuntu 20.04 Systeme ohne größere Anpassungen sind. Man arbeitet schließlich mit dem System und nicht am System.

Diese Gruppe ist zudem extrem wichtig, weil sie die Masse der Anwender stellt und verhindert, dass Linux am Desktop auf das Bedeutungsniveau von BSD absackt. Dank dieser Gruppe gibt es für Linux inzwischen selbstverständlich Clientprogramme für wichtige Dienste wie Zoom oder Teams. Das sah vor 15 Jahren noch ganz anders aus und ist eine Folge der Popularität von Ubuntu und der damit einhergehenden Standardisierung dessen, was gemeinhin als „Linux-Desktop“ begriffen wird.

Die Gruppe nimmt aber naturgemäß kaum Teil an irgendwelchen Diskussionen zur Weiterentwicklung von Linux. Normale macOS-Nutzer kommentieren schließlich auch nicht die Apple-Entwicklungen in irgendwelchen Foren. Die Gruppe fällt eher als träge Masse auf, die bei langanhaltenden Fehlentwicklungen oder durch gruppendynamische Prozesse von Distribution A zu Distribution B wandert. Diese Gruppe ist aber ziemlich tolerant gegenüber neuen Entwicklungen. Das kann man z. B. am Prozess GNOME 2 zu Unity zu GNOME Shell bei Ubuntu sehen, die meistens ausweislich der Zahlen einfach mit vollzogen wurde.

Gruppe 2: Lautstarke Minderheiten

Linux bietet unendlich Möglichkeiten. Die meisten Anwender arbeiten aber mit einem Standardsetup mit GNOME oder KDE Plasma und damit einem ähnlichen Aufbau, wie dem „Ubuntu-Mainstream“ und Partizipieren zumindest passiv an der Entwicklung. Andere Anwender schwören auf die Anpassbarkeit von Xfce, MATE oder irgendwelchen Openbox-Konstruktionen. Also jener Bereiche, bei denen Weiterentwicklungen nicht oder nur sehr langsam Einzug halten. Gerne auf demonstrativ veralteter Hardware, um die Genügsamkeit von Linux unter Beweis zu stellen und unter Verweigerung moderner „Trends“ wie Cloud oder Smartphone. Diese Anwender bringen ihre Minderheiteninteressen oft sehr offensiv in Debatten ein.

Exotische Setups gehen meist mit exotischen Distributionen einher. Exotisch bedeutet hier tatsächlich alles abseits des Ubuntu-Universums denn die Nutzungszahlen aller anderen Distributionen liegen (mutmaßlich) weiter hinter der „Ubuntu-Familie“. Hier haben wir aber noch viel weniger Zahlen. Für openSUSE Tumbleweed wurden 2016 mal 60.000 aktive Installationen bekannt gegeben, vermutlich sind das inzwischen ein paar mehr, aber es wird hier keine Millionen-Sprünge gegeben haben. Ich mag openSUSE, aber so viel Ehrlichkeit und Reflexionsvermögen sollte man als Kommentator haben. Fedora hat zwar 2019 Anstalten unternommen seine Benutzer zu zählen, aber Ergebnisse gibt es bisher nicht, die Verbreitung kann ich schwer schätzen, weil es hier erhebliche regionale Unterschiede zwischen Europa und den USA geben kann. Debian mag für das Gesamt-Ökosystem eine tragende Rolle spielen und im Server-Segment wichtig sein, Desktop-Installationen machen nach den Popcon-Zahlen nur eine Minderheit aus. Bei den Nicht-stabilen Distributionen spielt bestenfalls Manjaro und Arch eine nennenswerte Rolle, wie man auch der Steam Survey entnehmen kann.

Natürlich kann man nicht alle Distributionen über einen Kamm scheren, aber gemessen an der „Ubuntu-Familie“ haben sie alle eher kleine Benutzerzahlen. Man kann nämlich getrost bezweifeln, dass diese Distributionen auf die Millionen-Basis kommen, die Ubuntu für sich veranschlagt. Ansonsten würden beispielsweise die wenigen Mirror-Server andauernd in die Knie gehen. Alles andere läuft sowieso unter „ferner liefen“.

Hier bildet sich dann der Kern dessen, was ich als Gruppe 2 betrachte. Diese Gruppe hat sich mit dem System Linux wie es aktuell ist, sehr gut eingerichtet und benötigt keine Veränderung. Sie sieht keine Probleme und hat deshalb keinen Bedarf an wirklicher Entwicklung jenseits kosmetischer Pflege. Teile der Gruppe bekämpfen jedwede Veränderung geradezu aggressiv, weil sie es als Angriff auf ihr liebgewonnenes System wahrnehmen.

Das liegt auch daran, dass die Gruppe glaubt die Wahrheit gepachtet zu haben. Sie verwendet deshalb zur Begründung ihrer Positionen gerne die „Unix-Philosophie“ oder das „KISS-Prinzip“, um missliebige Entwicklungen zu diskreditieren.

In den Foren und Kommentarspalten machen diese Anwender aber einen überproportional großen Anteil aus. Auch in den Communitys der oben genannten Distributionen. Zum Problem wird das, wenn subjektive Äußerungen sich nicht mehr in Deckung mit Fakten bringen lassen. Stabile LTS-Distributionen verteufeln diese „Supporter“ bei jeder Gelegenheit (Beispiel hier) oder Snaps und Flatpaks werden mit Argumenten an der Schwelle von Unkenntnis zu Fake News bekämpft (Beispiele in den Kommentaren hier). Die überproportionale Präsenz in Foren und Kommentarspalten verleitet Gruppe 2 oft dazu zu glauben, sie wären „die Community“ oder von besonderer Relevanz für die Community.

Gruppe 3: Dort wo wie Entwicklung passiert (Red Hat)

Gruppe 2 hält sich zwar für sehr wichtig (sieht man daran, dass in den verlinkten Kommentaren von „Akzeptanz in der Community“ die Rede ist, wo eher die eigene Blase gemeint wird) ist es aber eigentlich nicht. Das wird wieder einige furchtbar aufregen, aber wer hier kommentiert, soll bitte gleich die letzte Innovation listen, die diese Gruppe hervorgebracht hat. Die Wünsche von exotischen Nutzern mit hochgradig individuell konfigurierten Linux-Setups sind einfach zu irrelevant im Hinblick auf die Marktanteile.

Die Entwicklung passiert bei Red Hat und hier vor allem im Testballon Fedora. Eine Zusammenfassung konnte man jüngst hier lesen. Ein wenig steuern noch SUSE und Canonical bei. Konkrete Projekte als Beispiele wären der usr-merge samt daraus hervorgehenden Möglichkeiten, alles rund um systemd, Pulseaudio, Pipewire, Desktop-Entwicklung im GNOME-Umfeld, Gedanken über Distributionen der Zukunft, Flatpaks und schließlich noch kpatch, um eine für Server relevante Funktion zu nennen. Diese Liste ließe sich endlos fortsetzen.

Diese Gruppe wird zwar regelmäßig von Gruppe 2 angepöbelt (kann man bei jedem Aufschlag von Lennart Poettering erleben) aber arbeitet trotzdem weiter an Linux. Ab einer gewissen Reife landen diese Entwicklungsergebnisse über Ubuntu dann bei der Masse der Anwender. Gruppe 2 zieht irgendwann mal nach oder nicht, kann man dann in internen Abstimmungsprozessen bei z. B. Debian nachverfolgen.

Zusammengefasst

Wichtig ist, was Gruppe 3 macht und wie Gruppe 1 darauf reagiert. Die zweite Gruppe führt zwar ihre lautstarken Binnendiskurse, geriert sich als Semi-Profis, wird aber von allen ernst zu nehmenden Entwicklern inzwischen ganz offenkundig ignoriert.

Noch arbeiten alle Gruppen letztlich mit dem gleichen Linux-System, aber je schneller die Entwicklung voranschreitet und je mehr sich Gruppe 2 dem verweigert, desto eher kann hier eine wirkliche Spaltung eintreten. Die Frage, ob die Lieblingsprojekte von Gruppe 2 den Sprung auf aktuelle Technologien wie Wayland schaffen, ist noch nicht beantwortet. Die sukzessive Verbreitung von Flatpaks oder Snaps bei Mainstream-Distributionen und Drittanbieter-Software wird hartnäckige Verweigerer zudem weiter isolieren.

Die Frage ist allerdings, wie sehr Gruppe 2 mit ihrer Ablehnung, undifferenzierter Ablehnung und partiellem Hass die Community so sehr vergiftet, das Linux insgesamt Schaden nimmt. Öffentliche Diskussionsprozesse über Veränderungen sind gegenwärtig bereits fast unmöglich, weil Akteure von Gruppe 2 jede konstruktive Diskussion sabotieren.

In diesem Sinne sollte jeder mal darüber nachdenken, wo er sich positioniert, welcher Gruppe er sich zuordnet, mit welchen Argumenten er sich beschäftigt und ob er vielleicht Nischenmeinungen reproduziert.

Der Artikel Spannungsfelder in der Linux Community erschien zuerst auf [Mer]Curius

Firewalls sind entgegen der landläufigen Meinung auch für Linux sinnvoll. Die meisten Distributionen setzen entweder auf Firewalld oder ufw. Auf Letzteres soll hier ein wenig eingegangen werden.

ufw als Kürzel für uncomplicated firewall ist ein relativ leicht zu konfigurierendes Frontend für iptables. Während Firewalld vor allem bei Red Hat, Fedora und openSUSE verbreitet ist, setzen Ubuntu und die offiziellen und inoffiziellen Derivate meist auf ufw. Beide Lösungen erfüllen ihren Zweck und reichen für Privatanwender aus.

Wichtig ist überhaupt eine Firewall zu nutzen. Die meisten Linux-Nutzer glauben immer noch dem alten Mythos, sie bräuchten keine Firewall, doch das war einmal. Linux-Desktopinstallationen sind nicht mehr minimalistisch und bewegen sich auch nicht mehr nur innerhalb des Heimnetzes.

Eine Firewall kann dann Sinn machen, wenn man ein mobiles Gerät besitzt und sich in fremde Netze einwählt. Nennt sich Notebook und dürfte bei den meisten Anwendern der Standardfall sein. Man verweist immer gerne auf Windows mit seinen vermeintlich vielen offenen Ports und Diensten, die man nicht braucht, aber auch bei Linux laufen viele Dienste, die außerhalb des Heimnetzes nicht gebraucht werden: CUPS, Avahi, KDE Connect, ggf. ein Samba-Share. Die Liste ließe sich sicher noch erweitern. Das ist jetzt grundsätzlich kein Problem, aber es schadet auch nicht, diese Ports bei unbekannten Netzwerken zu blockieren. Wer weiß schon, welche Sicherheitslücke demnächst in CUPS oder sshfs gefunden wird.

Den aktuellen Status von ufw kann man mit folgender Abfrage prüfen:

$ sudo ufw status

Die Ausgabe ist dann je nach Zustand Status: Inaktiv oder Status: Aktiv.

Mit folgendem Befehlen aktiviert bzw. deaktiviert man ufw.

$ sudo ufw enable
$ sudo ufw disable

ufw kennt drei Modi für Verbindungen: allow, deny reject. Der Unterschied zwischen letzteren beiden besteht darin, dass bei reject der Absender des Netzwerkpakets eine Nachricht über die Ablehnung bekommt. Der Vollständigkeit halber sei darauf hingewiesen, dass eine solche Reaktion manche Experten aus Sicherheitsgründen für nicht klug halten.

Normalerweise ist die Standardkonfiguration von ufw wenn weitere Einstellungen fehlen, eingehende Verbindungen zu blockieren und ausgehende Verbindungen zu erlauben. Die aktuelle Konfiguration kann mit dem verbose Befehl abgefragt werden. Die Ausgabe sollte wie folgt aussehen:

$ sudo ufw status verbose
Status: Aktiv
Protokollierung: on (low)
Voreinstellung: deny (eingehend), allow (abgehend), disabled (gesendet)
Neue Profile: skip

Sollten eingehende Verbindungen nicht per default blockiert werden kann dies mit folgendem Befehl nachgeholt werden:

$ sudo ufw default deny

Mit einem anschließenden Reload von ufw werden die Regeln aktiviert:

$ sudo ufw reload

Eine Konfiguration kann auf Basis von Services oder Application-Profilen erfolgen. Zusätzlich kann man einzelne Ports konfigurieren. Ein Service wie z. B. SSH lässt sich mit folgendem Befehl freigeben:

$ sudo ufw allow ssh

Besonders praktisch sind die mitgelieferten Profile. Diese werden direkt bei der Installation von Programmen mitgeliefert. Verfügbare Profile lassen sich mit folgendem Befehl finden:

$ sudo ufw app list

Normalerweise sollte mindestens ein Profil für CUPS vorhanden sein. Den Inhalt eines solchen Profils kann man sich ebenfalls anschauen:

$ sudo ufw app info CUPS
Profil: CUPS
Titel: Common UNIX Printing System server
Beschreibung: CUPS is a printing system with support for IPP, samba, lpd,
and other protocols.

Port:
  631

Anders als Firewalld kennt ufw keine Zonen, weshalb sich Verbindungen auch nicht klassifizieren und diese Klassifizierungen unterschiedlichen Netzwerken zugewiesen werden können. Das erleichtert zwar die Konfiguration, erlaubt aber nicht die Differenzierung zwischen privaten (vertrauenswürdigen) Netzwerken und öffentlichen Netzen.

Der Mehrwert von ufw für private Nutzer ist deshalb überschaubar. Bei einem ordentlich gepflegten Linux gibt es keine unnötigen offenen Ports. Wohl aber offene Ports, die man nicht in jedem Netzwerk benötigt. Firewalld bietet hier die Möglichkeit mit Zonen automatisiert zu differenzieren, ufw kennt nur zulässige Dienste oder Apps – egal in welchem Netz.

Der Artikel Firewall ufw für Linux konfigurieren erschien zuerst auf [Mer]Curius

Mi, 29. September 2021, Denys Konovalov

Am 28. September hat das Fedora-Projekt die erste Beta-Version der zukünftigen Fedora-Version 35 vorgestellt.

Neben GNOME 41 (wir berichteten) folgen mehrere fundamentale Neuerungen.

Eine neue Fedora Version bringt uns eine neue GNOME-Version - es war so und es bleibt so. Mit Fedora 35 dürfen sich die Anwender*innen auf GNOME 41 freuen - welches mit seinen zwar wenigen, aber doch wichtigen Änderungen die Benutzererfahrung mit GNOME als Arbeitsumgebung weiter aufpoliert.

In Verbindung dazu steht auch die Integration des Powerprofil-Dienstes, welcher eine Steuerung und Ausbalancierung des Verhältnisses zwischen Akkuverbrauch und Performance ermöglicht.

Doch nicht nur die GNOME-, sondern auch die KDE-Fans dürfen sich freuen: Fedora 35 bringt auch Fedora Kinoite mit sich - eine KDE-Variation von Fedora Silverblue, einer neuartigen OSTree-Distribution mit Fokus auf Immutable-Dateisystem und Flatpaks (genaueres ist in unserem Artikel beschrieben).

Bezogen auf Flatpaks gibt es eine weitere Neuerung, die alle, die öfters Fedora-Systeme einrichten müssen. freuen dürfte: ab Fedora 35 wird das Flathub-Repository automatisch eingebunden, wenn bei der Installation Drittanbieter-Paketquellen aktiviert werden.

Weitere Neuerungen beinhalten unter anderem die Einführung von WirePlumber, einem neuen PipeWire-Sitzungsmanager, und die automatische Nutzung von DNS-over-TLS bei Verfügbarkeit.

Wer sich über alle Änderungen in Fedora 35 informieren will, kann die offizielle Changelog hier lesen.

Wie bei allen Beta-Versionen ist es auch hier von den Entwicklern erwünscht, dass bemerkte Bugs und Probleme gemeldet werden, damit diese behoben werden können.

Was denkt ihr zu Fedora 35? Ist der Fokus auf neuen Technologien wie PipeWire eurer Meinung nach richtig? Was denkt ihr zur Zukunft von OSTree?

Diskutiere mit uns oder schreibe bei uns mit!

Quellen:

• https://fedoramagazine.org/announcing-fedora-35-beta/

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

Neuerungen von Thunderbird 91.1.2

Mit Thunderbird 91.1.2 hat die MZLA Technologies Corporation ein weiteres Update außer der Reihe veröffentlicht, welches diverse Korrekturen für die Versionsreihe 91 beinhaltet. Eine Übersicht über die in Thunderbird 91.1.2 behobenen Fehler gibt es in den Release Notes (engl.).

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

Ein kurzer Tipp fürs Interface Monitoring mit Icinga oder Nagios unter Debian.

Nach einem Update auf Debian Bullseye kann es vorkommen, dass einige Check Plugins fehlschlagen. So geschehen mit check_interfaces.

Das Plugin bringt nur noch folgende Ausgabe:

Plugin-Ausgabe
/usr/lib/nagios/plugins/check_interfaces: error while loading shared libraries: libnetsnmp.so.30: cannot open shared object file: No such file or directory

Zunächst kann man natürlich versuchen, die nötigen Dateien auf anderen Systemen zu suchen oder das Paket libsnmp40 zu installieren, leider bringt dies unnötige Arbeit, bzw. keine Abhilfe.

Die Lösung ist ein einfaches neu builden des Plugins:

apt-get update
apt-get -y install git build-essential libsnmp-dev

wget https://github.com/NETWAYS/check_interfaces/archive/refs/tags/v1.4.tar.gz

tar xvf v1.4.tar.gz

cd check_interfaces-1.4/

./configure --libexecdir=/usr/lib/nagios/plugins

make
make install

Der Zielpfad kann natürlich je nach Check Plugin Verzeichnis angepasst werden. Nach dem erneuten Builden unter Debian Bullseye sollte das Plugin wieder ohne Probleme funktionieren.

Di, 28. September 2021, Lioh Möller

Bei HOT DOG Linux handelt es sich nur im weiteren Sinne um eine Linux Distribution. HOT DOG steht für
Horrible Obsolete Typeface and Dreadful Onscreen Graphics for Linux und der Name ist Programm.

Das Projekt versucht auf einer modernen Basis das Look & Feel älterer Benutzeroberflächen nachzuahmen. Dazu gehören Windows 3.1 Hot Dog Stand, Amiga Workbench, Atari ST GEM und die Oberfläche von klassischen Macs. Für eine Nutzung wird ein Display mit einem niedrigen DPI Wert empfohlen, da die eingesetzten Grafiken ausschliesslich im Bitmap-Format in einer vordefinierten Grösse vorliegen. HOT DOG Linux kann wahlweise im 5:4 Landscape-Modus oder im 3:4 in Portrait-Modus genutzt werden.

Wer einen Blick auf den aktuellen Stand des Projektes werfen möchte, kann auf die Slackware -current basierten Live-Medien zurückgreifen. Aktuell stehen diese mit den Oberflächen Amiga Workbench und Mac zur Verfügung. Eine Installation auf eine Festplatte ist ebenfalls möglich.

Das Projekt befindet sich in einem vergleichsweise frühen Stadium und kann als experimentell bezeichnet werden.

Quelle: https://hotdoglinux.com

Di, 28. September 2021, Ralf Hersel

Der Bücherwurm (Debian 12 'Bookworm') steht zum Testen bereit. Wer Debian langweilig findet, kann sich am Test der Version 12 beteiligen und sich eines Besseren belehren lassen. Nach der Freeze- und Release-Phase von Debian 11 sind die Entwickler wieder an der Arbeit. Gnome 40.4 ist bereits in der Testversion 'Debian 12 Bookworm' enthalten. Herunterladen, ausprobieren, beim Testen helfen!

Gnome 40 ist ein Wendepunkt in der Gnome-Welt, da es die grafische Umgebung im Vergleich zu den 3er Versionen attraktiver, heller und weniger überladen macht. Man kann zu der reduzierten Desktop-Umgebung stehen wie man will; attraktiv und modern ist sie allemal. Mit der Version 41 wurden die Möglichkeiten für Einstellungen wieder erweitert, wie wir berichteten.

Debian 12 Testing hat die GNOME-Pakete auf die aktuellen 40er-Versionen hochgezogen und wird diese vermutlich Mitte 2023 als stabile Version veröffentlichen, soweit man dem bisherigen Release-Zyklus folgen möchte. Hier ist ein kurzes Video zu Debian 12 Testing mit GNOME 40:

Wer beim Testen des Bücherwurms helfen möchte, findet hier die Gelegenheit dazu. Um Debian 12 auszuprobieren, kann die wöchentlichen Builds herunterladen und in einer virtuellen Maschine testen.

Quelle: https://www.debian.org/releases/bookworm/releasenotes

Di, 28. September 2021, Lioh Möller

Q4OS 4.6 trägt den Codenamen Gemini und basiert auf Debian GNU/Linux 11. Bei der nun vorliegenden Version der Distribution handelt es sich um eine LTS-Veröffentlichung, welche mindestens 5 Jahre mit Aktualisierungen versorgt wird.

Als Desktopumgebung kommt wahlweise Plasma 5.20 oder der von KDE 3 abstammende Trinity Desktop in Version 14.0.10 zum Einsatz. Insbesondere der leichtgewichtige Trinity Desktop erfreut sich in der Community einer grossen Beliebtheit, da er sich auch auf älterer Hardware flüssig bedienen lässt. So erklärt sich auch, dass die Distribution nicht nur für 64bit/x64 und 32bit/i686pae Computer vorliegt, sondern auch eine Variante für ältere i386 Systeme ohne PAE-Extension erhältlich ist.

Der in Q4OS enthaltene Desktop Profiler wurde aktualisiert und bietet neu die Möglichkeit Anpassungen an der Desktopumgebung als Profil zu speichern und zu einem späteren Zeitpunkt wiederherzustellen.

Eines der wichtigsten Ziele war es laut den Projektverantwortlichen jedoch, dass sich der Plasma Desktop und Trinity parallel nutzen lassen. Mit der nun vorliegenden Version konnte dies nun erreicht werden.

Quelle: https://q4os.org/blog.html#news210927
Download: https://q4os.org/downloads1.html

Kali Linux 2021.3

Neues Quartal neues Kali Linux.

TLS 1.x

Mit Version 2021.3 wurden unter anderem alte Brötchen wieder aufgewärmt. So ist TLS 1.0 und TLS 1.1 unter OpenSSL wieder aktiv. Hintergrund sind mögliche Tests mit alten Systemen, welche noch mit den alten Standards laufen. Mit dem Befehl kali-tweaks lassen sich die Einstellungen allerdings jederzeit anpassen.

Virtuelle Maschinen

Virtuelle Maschinen haben eine bessere Unterstützung erhalten. So sollte nun ein Copy & Paste zwischen Host und virtuellem Zielsystem funktionieren. Unter Windows wurde mit dem Hyper-V Enhanced Session Mode die Möglichkeit für USB Sticks als lokale Ressource geschaffen.

Auch diese Funktion lässt sich über den Befehl kali-tweaks einrichten.

Smartwatches und Android 11 ohne TWRP

Neben der ersten Smartwatch TicHunter-Pro können Android 11 Smartphones nun via Magisk bespielt werden. Bisher war dies nur über das TWRP möglich. Das Projekt befindet sich allerdings noch am Anfang und ist mit Vorsicht zu genießen.

ARM

Kali für ARM hat neue Build Scripts erhalten, diese unterstützen nun auch RaspberryPi Zero.

Die aktualisierten Scripts erstellen ein neues Snakeoil Zertifikat. Als neue Standard Shell wird ZSH integriert. Dies lässt sich über das bereits bekannte kali-tweaks anpassen. Ebenfalls werden kalipi-config und kalipi-tft-config vorinstalliert.

Pinebook Freunde dürfen sich außerdem über einen neuen Kernel und einen hübscheren Bootscreen freuen.

Doku ist alles

Die neue Kali Tools Seite soll nicht unerwähnt bleiben. Sie bietet eine moderne und praktische Übersicht aller vorhandener Software.

BlackArch hat so eine Übersicht schon etwas länger und in der Vergangenheit ebenfalls ein neues Release veröffentlicht.

---

BlackArch 2021.09

Nachdem Kali Linux vorgelegt hatte, zieht BlackArch mit einer neuen Version nach.

Das auf Arch Linux basierende System bringt nach eigener Aussage nun 2700 Tools mit.

Welche Werkzeuge euch genau zur Verfügung stehen, könnt ihr dieser Tool-Liste entnehmen.

BlackArch 2021.09 läuft mit dem Kernel 5.13.10. Neben einem neuen Textinstaller gab es die üblichen Updates.

---

---

Übersicht 09/2021

 

Name	Version	Tools	Besonderes	Basis	GUI
Autopsy	4.18	???	The Sleuth Kit	Windows
BackBox	7.0	100+	AWS	Ubuntu	Xfce
BlackArch	2021.09	1750+	ArchLinux	ArchLinux	Multi
CAINE	11	100+	WinUFO	Ubuntu	Mate
DracOS	3.0		veraltet	LFS	DWM
DEFT Zero	2018.2		offline	Lubuntu 14.04	Lxde
Kali Linux	2021.03	300+	Plattformen	Debian Testing	Multi
Kali AppStore		40+		Android
LionSec	5.0		veraltet	Ubuntu
Matriux	v3 RC1		offline	Debian	Gnome
NST	34	???	Server integriert	Fedora
NetSecL OS	6.0		veraltet	OpenSuse	Lxde
Paladin	7.0			Ubuntu
Parrot OS	4.11.2	700+	Cloud fähig	Debian Buster	MATE/KDE
Pentoo	2018.0 RC7.1		veraltet	Gentoo	Xfce
Ronin			veraltet	Lubuntu	Lxde
Sans SIFT	3.0		veraltet	Ubuntu

Beim Durchwühlen des Internets bin ich auf eine Perle gestoßen, die ich hier festhalten möchte. In „Bash Script to Parse and Analyze Nginx Access Logs“ stellt Ruan Bekker ein kurzes Bash-Skript vor, welches die NGINX Access Logs analysiert, um einen Bericht mit folgenden Sektionen auszugeben:

• Top 10 Request IPs (aus dem aktuellen Access Log)
• Top Request Methods (aus dem aktuellen Access Log)
• Top 10 Request Pages (aus dem aktuellen Access Log)
• Top 10 Request Pages (aus dem aktuellen und Gzipten Logs)
• Top 10 HTTP 404 Page Responses (aus dem aktuellen und Gzipten Logs)

Ich selbst nutze aktuell den Fork von Marc Brunet, welchen ich meinen My-IT-Scripts hinzugefügt habe:

#!/bin/bash

# URL: https://github.com/Tronde/My-IT-Scripts/blob/master/bash/analyze_nginx_access_logs.sh

# variables
LOGFILE="/var/www/jkastning/sites/logs/www.my-it-brain.de_access.log"
LOGFILE_GZ="/var/www/jkastning/sites/logs/www.my-it-brain.de_access.log.*"
RESPONSE_CODE="200"

# functions
filters(){
grep -w $RESPONSE_CODE \
| grep -v "\/rss\/" \
| grep -v robots.txt \
| grep -v "\.css" \
| grep -v "\.jss*" \
| grep -v "\.png" \
| grep -v "\.ico"
}

filters_404(){
grep -w "404"
}

request_ips(){
awk '{print $1}'
}

request_method(){
awk '{print $6}' \
| cut -d'"' -f2
}

request_pages(){
awk '{print $7}'
}

wordcount(){
sort \
| uniq -c
}

sort_desc(){
sort -rn
}

return_kv(){
awk '{print $1, $2}'
}

request_pages(){
awk '{print $7}'
}

return_top_ten(){
head -10
}

## actions
get_request_ips(){
echo ""
echo "Top 10 Request IP's:"
echo "===================="

cat $LOGFILE \
| filters \
| request_ips \
| wordcount \
| sort_desc \
| return_kv \
| return_top_ten
echo ""
}

get_request_methods(){
echo "Top Request Methods:"
echo "===================="
cat $LOGFILE \
| filters \
| request_method \
| wordcount \
| return_kv
echo ""
}

get_request_pages_404(){
echo "Top 10: 404 Page Responses:"
echo "==========================="
zgrep '-' $LOGFILE $LOGFILE_GZ\
| filters_404 \
| request_pages \
| wordcount \
| sort_desc \
| return_kv \
| return_top_ten
echo ""
}


get_request_pages(){
echo "Top 10 Request Pages:"
echo "====================="
cat $LOGFILE \
| filters \
| request_pages \
| wordcount \
| sort_desc \
| return_kv \
| return_top_ten
echo ""
}

get_request_pages_all(){
echo "Top 10 Request Pages from All Logs:"
echo "==================================="
zgrep '-' --no-filename $LOGFILE $LOGFILE_GZ \
| filters \
| request_pages \
| wordcount \
| sort_desc \
| return_kv \
| return_top_ten
echo ""
}

# executing
get_request_ips
get_request_methods
get_request_pages
get_request_pages_all
get_request_pages_404

Selbstverständlich erhalte ich damit keine genauen Statistiken, da meine Logs nach einem Monat automatisch gelöscht werden. Für einen kurzen Rückblick und der Erstellung eines monatlichen Berichts scheint das kleine Skript jedoch gut geeignet zu sein. Ich probiere es gerade aus, um zu sehen, wie gut es mir auf Dauer gefällt.

Auf Basis des ersten Skripts habe ich ein zweites geschrieben, mit dessen Hilfe ich die Requests für einen spezifischen Beitrag abfragen kann (Quelle):

#!/bin/bash

# variables
LOGFILE="/var/www/jkastning/sites/logs/www.my-it-brain.de_access.log"
LOGFILE_GZ="/var/www/jkastning/sites/logs/www.my-it-brain.de_access.log.*"
RESPONSE_CODE="200"
ARG1=$1

# functions
filters(){
grep -w $RESPONSE_CODE \
| grep -v "\/rss\/" \
| grep -v robots.txt \
| grep -v "\.css" \
| grep -v "\.jss*" \
| grep -v "\.png" \
| grep -v "\.ico"
}

request_ips(){
awk '{print $1}'
}

request_page(){
awk '{print $7}' \
| grep -w $ARG1
}

wordcount(){
sort \
| uniq -c
}

return_kv(){
awk '{print $1, $2}'
}

get_request_page(){
echo "Page requests in current log:"
echo "====================="
cat $LOGFILE \
| filters \
| request_page \
| wordcount \
| return_kv
echo ""
}

get_request_page_all(){
echo "Page requests in all logs (last month):"
echo "==================================="
zgrep '-' --no-filename $LOGFILE $LOGFILE_GZ \
| filters \
| request_page \
| wordcount \
| return_kv
echo ""
}

# execute
get_request_page
get_request_page_all

Der folgende Code-Block zeigt ein Beispiel, wie das Skript angewendet wird. Dabei wird der Permalink als Argument übergeben:

:~/bin$ sh get_page_requests_from_nginx_access_logs.sh kommentar-linux-container-spreu-und-weizen
Page requests in current log:
=====================
262 /wordpress/kommentar-linux-container-spreu-und-weizen/
6 /wordpress/kommentar-linux-container-spreu-und-weizen/feed/

Page requests in all logs (last month):
===================================
5124 /wordpress/kommentar-linux-container-spreu-und-weizen/
49 /wordpress/kommentar-linux-container-spreu-und-weizen/feed/
2 /wordpress/wp-json/oembed/1.0/embed?url=https://www.my-it-brain.de/wordpress/kommentar-linux-container-spreu-und-weizen/

Noch nicht schön, aber zweckmäßig.

Was haltet ihr davon? Falls ihr beim Drübergucken zufällig noch einen Fehler in den Skripten entdeckt, freue ich mich, wenn ihr mir einen Kommentar hinterlasst.

Christian Schaller hat in seinem Blog sich sehr ausführlich zur vergangenen und künftigen Entwicklung von Fedora Workstation (also der Desktop-Variante der Distribution) geäußert.

Den Artikel „Fedora Workstation: Our Vision for Linux Desktop“ möchte ich allen interessierten Linux-Nutzerns empfehlen. Neben einem Resümee der Ausgangssituation und getroffenen Entscheidungen kann man bereits einen Ausblick auf das werden, was konzeptionell angedacht wird. Besonders interessant ist die Schilderung, wie komplex die Entwicklung einer klassischen Distribution mit normaler Paketverwaltung ist und dass dieses Konzept eigentlich keine sinnvolle Variante für schnelle Entwicklungszyklen ist. Wenn es überhaupt eine langfristige Zukunft jenseits Status quo-orientierter Distributionen hat.

Die Zielrichtung von Fedora Workstation ist immer noch ein Szenario, das sich momentan in der Silverblue-Edition testen lässt. Das bedeutet eine gänzlich neue Art Linux-Distribution. Das Betriebssystem wird read-only eingebunden, Anwendungen primär über Flatpaks installiert und weiterführende Ansprüche werden mit Toolbox anvisiert. Dabei handelt es sich letztlich um Container mit Systemwerkzeugen.

Weitere Themen sind dann noch Wayland, Pipewire und LVFS. Ebenfalls sehr interessante Baustellen und für viele Community-Lieblinge wie MATE oder Xfce ein riesiges Problem, weil die Manpower für solche Entwicklungsleistungen eigentlich zu knapp ist.

An dem Artikel sieht man wieder sehr deutlich, wie wichtige Red Hat bzw. Fedora für Linux ist. Nahezu alle wichtigen Zukunftsthemen werden dort bearbeitet, viele wichtige Projekte gestartet und entwickelt. Diese sickern dann nach und nach in die anderen Distributionen.

Interessierte Anwender sollten sich außerdem Silverblue mal ansehen. Momentan halte ich Silverblue noch nicht für komplett alltagstauglich und die Fedora-Entwickler teilen diese Meinung scheinbar. Die Fortschritte sind aber immens und ich persönlich denke, dass diese Variante einer Linux-Distribution bereits in den nächsten Jahren das normale Desktop-Linux für Endanwender werden kann.

OpenSUSE experimentiert schließlich mit einem ähnlichen Konzept, das aber einen vollständig anderen technischen Ansatz hat und Ubuntu könnte Snaps weiter aufbohren und auf eine ähnliche Strategie schwenken. Sofern man an der Eigenentwicklung festhält und sich nicht letztlich doch wieder dem Linux-Mainstream beugt.

Der Artikel Lesetipp: Vision für Fedora Workstation erschien zuerst auf [Mer]Curius

Der systemd-Entwickler schreckt mal wieder die Linux-Gemeinde auf. Nicht ganz unerwartet befasst er sich mit der Ar,t wie die meisten Linux-Distributionen Daten verschlüsseln und Integrität gewährleisten. Ein notwendiger Weckruf für die oft bräsige Community.

Poettering befasst sich bereits seit längerem mit der Datensicherheit, LUKS und TPM. Der aktuelle Blogpost von ihm kommt daher nicht gänzlich unerwartet. Eine kurze Zusammenfassung und Bewertung kann man auch bei Golem lesen.

Einleitend befasst er sich mit dem aktuellen Status quo. Hier ist er sogar in vielen Fällen zu optimistisch, denn die Situation ist oft noch viel schlimmer.

Die meisten Distributionen verschlüsseln standardmäßig gar nicht und drängen diese Möglichkeit ihren Nutzern auch nur dezent auf. Linux ist hier schon länger deutlich unsicherer als die meisten anderen Betriebssysteme – abgesehen nur von der Windows-Home-Edition. Linux-Distributionen verschlüsseln Daten mittels einer LUKS/Cryptsetup-Lösung, die frühere verbreitete eCryptFS-Methode ist kaum noch verbreitet. Basale TPM-Unterstützung ist zwar vorhanden, wird aber kaum genutzt, obwohl (wegen entsprechender Microsoft-Vorgaben) alle halbwegs neuen Geräte einen TPM-Chip aufweisen.

Ein weiterer Baustein in der Validierungskette ist Secureboot. Hier ist Poettering wieder mal viel zu optimistisch, wenn er schreibt, dass die meisten Distributionen hierüber absichern. Insbesondere die vielen Kleinprojekte, aber auch so beliebte Distributionen wie Arch Linux oder Manjaro bieten kein Secureboot an bzw. zumindest nicht als Standard. Im besten Fall nutzt eine Distribution Secureboot und validiert via Shim Bootloader und Kernel. Eine lückenlose Valididerungskette inklusive Initrd und Betriebssystem erfolgt bei keiner Distribution. Dazu hatte ich mich hier auch schon mal geäußert. Das nicht verifizierte Initrd wird entpackt und fragt nach einem Passwort, um das LUKS-Volume zu entschlüsseln. Ab jetzt sind die Daten verfügbar. Der Benutzerlogin ist dann nur noch Kosmetik und wird von vielen LUKS-Nutzern bei Einzelnutzung auch per Autologin übersprungen.

Die aktuelle Vorgehensweise hat gleich mehrere offene Flanken. Vor allem schützt sie nicht, wenn die Festplatte physisch gestohlen oder komplett kopiert wird. Der Angreifer hat danach alle Zeit der Welt, um sich mit der Verschlüsselung und ihrer Umgehung zu beschäftigen. Ein weiteres Szenario ist die unbeobachtete Kompromittierung des Systems, genant Evil Maid Angriff.

Poettering kommt deshalb auch zu dem harten Schluss, dass alle anderen Betriebssysteme – ChromeOS, Android, Windows und macOS – die Daten der Anwender besser schützen.

Zur Abhilfe schlägt Poettering einige Punkte vor. Initrd müsste beim Start authentifiziert werden, ebenso das System unter /usr (was einen vollständigen usr-merge voraussetzt – Hallo Debian) und die Verschlüsselung des Benutzerverzeichnisses sollte an das Nutzerpasswort gebunden werden und nicht an das System. Besser wären noch Lösungen ohne Passwörter, wie beispielsweise FIDO2. Hier enteilt Microsoft Windows mit Hello Linux sowieso hoffnungslos.

Die Lösungsvorschläge basieren natürlich viel auf Entwicklungen in systemd (z. B. system-cryptenroll, systemd-home), aber auch auf Kryptofunktionen im Kernel wie dm-Verify und dm-Integrity. Ingesamt setzt Poettering auf eine viel stärkere Einbeziehung der sowieso verfügbaren TPM-Technik in die Sicherheitskonzepte der Distributionen. In diesem Zusammenhang wendet er sich auch massiv gegen nicht faktengestützte Vorurteile gegenüber TPM.

Diese Ideen sind natürlich weit entfernt davon, produktiv einsetzbar zu sein. Vermutlich werden sie am ehesten bei Fedora umgesetzt und dann sukzessive bei weiteren Distributionen.

Leider werden viele schon alleine deshalb dagegen arbeiten, weil die Ideen von Poettering kommen und systemd bei vielen nicht faktengestützte Vorurteile hervorrufen. Zudem haben viele Linux-Nutzer sich bequem in der Vergangenheit eingerichtet und leugnen die Herausforderungen der Gegenwart (von der Zukunft ganz zu schweigen).

Der Artikel Lennart Poettering hinterfragt Linux Verschlüsselung erschien zuerst auf [Mer]Curius

Fr, 24. September 2021, Ralf Hersel

Heute ist die Beta-Version von Ubuntu 21.10 erschienen und gibt der Community die Möglichkeit, die neue Version ausgiebig zu testen, bevor am 14. Oktober das finale Release der Herbstausgabe der Canonical-Distribution 'Impish Indri' herausgegeben wird. Eine der spannendsten Fragen ist, wie die Entwickler den stark veränderten GNOME 40 Desktop an die Gewohnheiten der Ubuntu-Anwenderinnen angepasst haben.

Wie auf dem Screenshot zu erkennen ist, hat man das Ubuntu-Dock an der linken Seite beibehalten. In der Standardeinstellung bleibt das Dock permanent geöffnet. Im Gegensatz zum originalen GNOME 40, wird nach dem Start in Ubuntu 21.10 nicht die Aktivitätenübersicht geöffnet, stattdessen bleibt man beim gewohnten Verhalten, die leere Arbeitsfläche anzuzeigen. Über Vor- und Nachteile beider Verfahren berichteten wir bereits.

In Ubuntu 21.10 kommt die Version GNOME 40.4 zum Einsatz, inklusive der 40er-Versionen der GNOME-Anwendungen, wie z. B. Dateien (Nautilus). Ebenfalls enthalten ist ein überarbeitetes Yaru-Thema mit einer hellen und einer dunklen Ansicht; das gemischte helle und dunkle Thema aus früheren Versionen ist nun leider verschwunden.

Impish Indri setzt auf den Linux Kernel 5.13 und aktualisiert auf GNU C Library 2.34, GCC 11, LLVM 13, und GNU Binutils 2.37. Der Standardwebbrowser ist Firefox 92 als Snap-Paket, sowie LibreOffice 7.2 für die Büroarbeiten. Neben anderen Verbesserungen funktioniert die Wayland-Sitzung nun auch bei Verwendung der proprietären NVIDIA-Grafiktreiber, PulseAudio 15 ist standardmässig mit Unterstützung für Bluetooth LDAC-, AptX- und HFP-Profile für eine bessere Audioqualität enthalten, und PipeWire ist ebenfalls für eine verbesserte Audiowiedergabe vorinstalliert.

Wer sich am Test von Ubuntu 21.10 Beta beteiligen möchte oder gerne einen Vorgeschmack auf die Herbstversion hätte, kann die Distribution hier herunterladen:

Quelle: https://releases.ubuntu.com/21.10/

Mozilla hat mit Firefox 92.0.1 ein Update außer der Reihe für seinen Desktop-Browser veröffentlicht.

Download Mozilla Firefox 92.0.1

Mit dem Update auf Firefox 92.0.1 behebt Mozilla ein Problem, welches unter bestimmten Umständen verursachen konnte, dass die Suchleiste keinen Schließen-Button anzeigte. Außerdem wurde ein Problem behoben, welches für manche Linux-Nutzer verursachte, dass bei der Wiedergabe von Medien kein Ton zu hören war. Darüber hinaus wurde das Suchmaschinen-Logo von DuckDuckGo aktualisiert und diverse Anpassungen in Vorbereitung auf ein bevorstehendes Experiment für Nutzer in den USA wurden integriert.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

nano etherpad-lite/settings.json

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

...

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

...

"requireAuthentication": true,

...

"trustProxy": true,

...

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

...

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

...

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

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

...

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

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

Diese wird mit folgendem Inhalt befüllt:

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

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

[Install]
WantedBy=multi-user.target

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

systemctl enable etherpad
systemctl start etherpad

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

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

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

    server_name example.org;

    client_max_body_size 512m;

    location / {

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

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

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

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

Mi, 22. September 2021, Ralf Hersel

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

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

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

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

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

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

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

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

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

Paketverwaltung

Kennzeichen der klassischen Paketverwaltung:

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

Vorteile der klassischen Paketverwaltung:

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

Nachteile der klassischen Paketverwaltung:

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

Neue Formate Flatpak / Snap

Kennzeichen der neuen Formate Flatpak / Snap:

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

Vorteile der neuen Formate Flatpak / Snap:

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

Nachteile der neuen Formate Flatpak / Snap:

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

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

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

Neuerungen von Thunderbird 91.1.1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Was ist ein In-Place-Upgrade?

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

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

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

In-Place-Upgrade vs. Neuinstallation

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

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

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

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

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

Das Upgrade von RHEL 7 auf RHEL 8

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

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

Limitierungen

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

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

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

Vorbereitung

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

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

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

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

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

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

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

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

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

Pre-Upgrade-Bericht erstellen

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

Durchführung des In-Place-Upgrade

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

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

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

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

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

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

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

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

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

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

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

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

Hier sieht alles gut aus.

Post-Upgrade-Tasks

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

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

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

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

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

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

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

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

Fazit

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

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

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

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

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

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

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

[2] Red Hat Enterprise Linux technology capabilities and limits

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

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

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

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

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

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

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

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

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

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

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

2007

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

Geschichte von Android, abgerufen am 17.09.2021

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

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

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

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

Chromebook Hilfe, abgerufen am 17.09.2021

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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