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

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

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.

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.

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.