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), um auf externe Festplatten zu sichern und zusätzlich sichere ich mittels Déjà Dup auf mein Synology NAS.

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

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

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

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

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

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

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

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

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

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

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

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

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

Neuerungen von Thunderbird 78.14

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

Neuerungen von Thunderbird 91.1

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

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

Mi, 8. September 2021, Ralf Hersel

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

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

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

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

Weitere Details stehen in den Release Notes:

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

Mi, 8. September 2021, Marco

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

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

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

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

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

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

Firefox 92 bringt Detail-Verbesserungen

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

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

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

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

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

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

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

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

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

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

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

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

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

Geschlossene Sicherheitslücken

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

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

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

Neue Versionierung

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

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

Änderungen

Folgende Änderungen fallen im Changelog auf:

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

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

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

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

• ERR_GET_FUNC() wurde vollständig entfernt.

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

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

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

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

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

• Linux' Kernel TLS wird nun unterstützt.

• Ausgaben verschiedener Kommandos wurden leicht angepasst.

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

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

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

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

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

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

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

Neue Lizenz

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

Kurzeinordnung

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

Mo, 6. September 2021, Ralf Hersel

OpenWrt ist eine Linux-Distribution für eingebettete Systeme wie CPE-Router, Smartphones oder Pocket-Computer. OpenWrt bietet ein voll beschreibbares Dateisystem und beinhaltet den Paketmanager opkg. Das ist insbesondere für den Einsatz in CPE- und WLAN-Routern einzigartig. Die Paket-Quellen beinhalten mehr als 15.000 Software-Pakete. Mit diesen kann der Router umfassend konfiguriert und um viele Funktionen erweitert werden, die von der Firmware des Geräteherstellers nicht unterstützt werden. Nun ist die Version 21.02 der Distribution erschienen.

OpenWrt 21.02 enthält über 5800 Commits seit der vorherigen Version 19.07 und befindet sich seit etwa eineinhalb Jahren in der Entwicklung. Die Highlights der neuen Version sind:

WPA3-Unterstützung standardmässig enthalten
WPA3 wurde bereits in Version 19.07 unterstützt, war aber nicht in den Standardpaketen der OpenWrt-Images enthalten. Mit 21.02 werden alle Pakete, die für die Bereitstellung von WPA3 erforderlich sind, standardmässig in OpenWrt-Images installiert. WPA3 wird von den meisten Wifi-Treibern in OpenWrt unterstützt.

TLS- und HTTPS-Unterstützung standardmässig enthalten
TLS-Unterstützung wird nun standardmässig in OpenWrt-Images bereitgestellt, einschliesslich der vertrauenswürdigen CA-Zertifikate von Mozilla. Das bedeutet, dass wget und opkg nun das Abrufen von Ressourcen über HTTPS sofort unterstützen. Auf den opkg-Download-Server wird standardmässig über HTTPS zugegriffen. OpenWrt wechselte von mbedTLS zu wolfSSL als Standard-SSL-Bibliothek. mbedTLS und OpenSSL sind weiterhin verfügbar und können manuell installiert werden.

Erste DSA-Unterstützung
DSA steht für Distributed Switch Architecture und ist der Linux-Standard für den Umgang mit konfigurierbaren Ethernet-Switches. OpenWrt 21.02 kommt mit anfänglicher Unterstützung für DSA, die das swconfig-System ersetzt, das OpenWrt bisher verwendet hat. Nicht alle Ziele wurden portiert: einige Geräte verwenden noch swconfig, während einige Geräte bereits zu DSA gewechselt haben.

Erhöhte Mindestanforderungen an die Hardware: 8 MB Flash, 64 MB RAM
Aufgrund der Einführung neuer Funktionen und der allgemeinen Vergrösserung des Linux-Kernels benötigen Geräte nun mindestens 8 MB Flash und 64 MB RAM, um eine Standardversion von OpenWrt auszuführen. Mehr Flash-Speicher wird für die Erweiterbarkeit empfohlen.

Neue Netzwerkkonfigurationssyntax und board.json Änderung
Es gibt mehrere Änderungen an der Syntax der Netzwerkkonfiguration in /etc/config/network:

• in config interface wurde die Option ifname in device umbenannt (da sie sich auf einen Geräteabschnitt bezieht)
• in config device vom Typ bridge wurde ifname in ports umbenannt
• Bei Neuinstallationen erstellt die generierte Konfiguration nun separate Abschnitte für die Konfiguration der Schicht 2 (config device) und der Schicht 3 (config interface).

Die alte Syntax wird weiterhin unterstützt, um den Übergang zu erleichtern, und es gibt keine automatische Migration beim Upgrade.

Neu unterstützte Hardware-Targets
Es wurde ein neues Realtek-Target hinzugefügt, das häufig in verwalteten Switches zu finden ist. Dadurch ist es nun möglich, OpenWrt auf Geräten mit einer grossen Anzahl von Ethernet-Ports zu betreiben. Darüber hinaus wurden neue bcm4908- und Rockchip-Targets hinzugefügt. Die bestehenden Targets wurden um Unterstützung für viele neue Boards ergänzt.

Gestrichene Hardware-Targets
Das ar71xx-Target ist in OpenWrt 19.07 veraltet und wurde schrittweise durch ath79 ersetzt. Mit OpenWrt 21.02 wurde das ar71xx nun entfernt und Benutzer müssen stattdessen ath79 verwenden. Andere Targets wurden ebenfalls entfernt: cns3xxx, rb532 und 'samsung'.

ASLR aktiviert
Netzwerkexponierte Userspace-Anwendungen werden als positionsunabhängige ausführbare Dateien (PIE) gelinkt, um eine vollständige Unterstützung der Address Space Layout Randomization (ASLR) zu ermöglichen. Dadurch wird es für Angreifer schwieriger, OpenWrt auszunutzen.

Kernel mit Container-Unterstützung
Mehrere Linux-Kernel-Kompilieroptionen, die für Linux-Container (LXC) und procd-ujail benötigt werden, sind für die meisten Targets standardmässig aktiviert. Dies ermöglicht die Verwendung von LXC und ujail mit den normalen Release-Builds.

SELinux-Unterstützung
Es ist möglich, OpenWrt mit SELinux-Unterstützung zu kompilieren. Diese ist derzeit standardmässig nicht aktiviert.

Weitere Neuigkeiten und Änderungen finden sich in den Release Notes:

Quelle: https://openwrt.org/releases/21.02/notes-21.02.0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Nachtrag vom 28.09.2021

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

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

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

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

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

• Qogir Icon Theme
• Qgoir GTK Theme

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

Do, 2. September 2021, Ralf Hersel

Linux Lite ist eine einsteigerfreundliche Linux-Distribution, die auf der Long-Term-Support-Version (LTS) von Ubuntu basiert und den Xfce-Desktop enthält. Die neueste Version des Projekts, Linux Lite 5.6, basiert auf Ubuntu 20.04 LTS und bietet eine Reihe von Annehmlichkeiten und Upgrades. Python 3 wird nun standardmässig verwendet, es ist möglich, die Distribution über den Willkommensbildschirm auf dem Live-Medium zu installieren, und das Tool "Lite Tweaks" bietet die Möglichkeit, temporäre Dateien, die vom Brave-Browser verwendet werden, zu bereinigen.

"Linux Lite 5.6 Final steht ab sofort zum Download und zur Installation bereit. Diese Version enthält Aktualisierungen des Hilfe-Handbuchs - unsere ausführliche, leicht verständliche Linux-Lite-Anleitung, Du kannst Linux Lite jetzt direkt von Lite Welcome aus installieren, ein aktualisiertes Papirus-Symbolthema, 2 neue Funktionen für Lite Tweaks, die Einführung des digitalen Download-Modells 'Pay what You Want', 7 neue Hintergrundbilder, die Standardversion von Python ist jetzt auf Python3 eingestellt, und eine Vielzahl von Fehlerkorrekturen und Verbesserungen für unsere Zielgruppe. Wenn Du von Windows kommst, wirst Du feststellen, dass dies eine solide, stabile Version ist, die dir den Übergang zu einem linuxbasierten Betriebssystem erleichtern wird." so das Projektteam.

Details zum Release sowie Screenshots finden sich in der Release-Ankündigung:

Quelle: https://www.linuxliteos.com/forums/release-announcements/linux-lite-5-6-final-released/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Do, 2. September 2021, Ralf Hersel

Linux From Scratch (LFS) ist ein Projekt, das eine Schritt-für-Schritt-Anleitung bietet, um sein eigenes, individuelles Linux-System zu erstellen, und zwar vollständig aus dem Quellcode. Nun gibt Bruce Dubbs vom LFS-Team die Veröffentlichung von LFS Version 11.0 bekannt.

Der Grund für die Erhöhung der Versionsnummer ist, dass diese Version nicht mehr das "Split-User"-System verwendet. Das heisst, wie bei den meisten aktuellen Distributionen, ist /bin ein symbolischer Link zu /usr/bin. Ebenso sind /lib und /sbin symbolische Links zu ihren /usr-Gegenstücken.

Zu den weiteren grösseren Änderungen gehören Aktualisierungen der Toolchain für gcc-11.2.0, glibc-2.34 und binutils-2.37. Der Linux-Kernel wurde ebenfalls auf die Version 5.13.12 aktualisiert. Insgesamt wurden 40 Pakete seit der letzten Veröffentlichung aktualisiert.

Ein zentraler Bestandteil des Projektes ist das LFS-Buch. Es liefert den Hintergrund und die Anweisungen, die man benötigt, um ein eigenes System zu entwerfen und zu bauen. Obwohl dieses Buch eine Vorlage bietet, die zu einem korrekt funktionierenden System führt, steht es jedem frei, die Anleitungen zu ändern, um sie an eigene Bedürfnisse anzupassen. Auch das Buch ist mit einigen Änderungen am Text in Version 11 erschienen.

Zusammen mit dieser Veröffentlichung wird auch eine neue Version von LFS mit dem systemd-Paket bereitgestellt. Dieses Paket implementiert den neueren systemd-Stil der Systeminitialisierung und -steuerung und ist in den meisten Paketen mit LFS konsistent.

Wer sich für die Tiefen einer GNU/Linux Distribution interessiert, der sei auch Lioh Möllers Linux Kurs empfohlen. Darin erfährt man auf Basis der Distribution Slackware alles darüber, wie man ein Linux-System Schritt für Schritt aufbaut.

Quelle: https://www.linuxfromscratch.org/news.html

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

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

Neuerungen

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

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

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

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

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

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

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

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

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

Ärgernisse

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

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

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

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

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

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

Versionsnummern

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

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

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

Plattformen (Architekturen)

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

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

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

• Unterstützte Architekturen
• Ports

Fazit

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

Quellen und Testberichte

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

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

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

Di, 31. August 2021, Ralf Hersel

Während im Oktober die Ubuntu Version 21.10 "Impish Indri" erscheinen wird, liegt bereits der Entwurf des Releaseplans für die kommende Long-term-support Version 22.04 auf dem Tisch. Brian Murray veröffentlichte diese auf Canonicals Discourse Kanal.

Für Ubuntu 22.04 wird es als LTS-Version mindestens 5 Jahre Support geben. Die Feature Freeze-Phase ist für den 24. Februar angesetzt, zusammen mit dem Debian Import Freeze, während die Kernel Freeze- und Final Freeze-Phasen für den 7. bzw. 14. April geplant sind. Die fertige Version wird am 21. April 2022 erscheinen. Als Desktop-Umgebung wird man endlich auf die GNOME 40 Serie wechseln (vermutlich wird ein GNOME 41 oder 42 enthalten sein). Welchen Namen das übernächste Release tragen wird, ist noch nicht bekannt, da der Kosenamen immer erst kurz nach dem Erscheinen der vorherigen Version bekannt gegeben wird, also im Oktober 2021.

Quelle: https://discourse.ubuntu.com/t/jj-release-schedule/23906

Mo, 30. August 2021, Niklas

Wie wir schon vor einigen Wochen berichteten, hat das Haiku Projekt nach etwas mehr als einem Jahr eine neue stabile Version seines quelloffenen BeOS Nachfolgers veröffentlicht. Nach dem Start lassen sich zunächst keine Unterschiede erkennen: Desktop, Icons, Taskleiste, ... - Alles sieht aus wie immer.

Die meisten Änderungen fanden unter der Haube statt, wie etwa bei verbesserten Treibern oder aktualisieren Programmbibliotheken. Haiku Beta 3 startet sogar auf meinem Medion Akoya von 2019 ohne weiteres, welches mit Beta 2 im Bootscreen hängen geblieben ist. Da hier aber Treiber für Touchscreen und Touchpad fehlen und das WLAN nicht richtig funktioniert, beende ich dieses Experiment schnell wieder.

Die viel angepriesenen Aktualisierungen von HaikuWebKit und dem WebPositive Browser sehen beim HTML5 Test eher enttäuschend aus: Beta 2 kommt auf 382 Punkte, Beta 3 nur noch auf 367. Die Unterstützung für die Eingabefeldtypen Datum, Zeit und Monat wurden anscheinend entfernt. Tatsächlich wurden diese aber auch in Beta 2 nicht unterstützt. Die entsprechenden Eingabefelder waren unsichtbar, bekamen beim Klick darauf einen schwarzen Rahmen und konnten nicht beschrieben werden. In Beta 3 tauchen sie immerhin in Form eines normalen Textfelds auf, das von Hand ausgefüllt werden kann.

Ansonsten sind die Messergebnisse identisch, wobei in der Praxis doch erhebliche Verbesserungen bei WebPositive in Beta 3 spürbar sind. In Beta 3 werden einige zusätzliche Unicode Icons unterstützt, die bei Beta 2 noch nicht vorhanden waren, was sich bereits auf der HTML5 Test Seite zeigt. Eine vollständige Liste der Unicode Icons gibt es hier. Was hingegen leider weiterhin gar nicht unterstützt wird, sind Icon Fonts wie Font Awesome, die für die Bedienelemente von zahlreichen Webseiten verwendet werden.

Beim WLAN erkenne ich Verbesserungen, diese sind aber eher subjektiv. Das WLAN meines Testlaptops, Intel PRO Wireless 3945ABG, hat auch vorher schon funktioniert, jedoch mit regelmässigen Verbindungsabbrüchen. In Beta 3 habe ich das Gefühl, dass die Abbrüche nicht mehr so häufig auftreten, ganz behoben wurde das Problem jedoch nicht.

Gerade mit Blick auf dieses Problem sind die Verbesserungen am Paketmanagement aber sehr deutlich zu spüren. Früher musste man das komplette Systemupdate mit allen Paketen wieder von null beginnen, wenn irgendwann zwischendrin die Verbindung unterbrochen wurde. Grössere Aktualisierungen waren an meinem Testlaptop nur mit LAN Verbindung oder durch Aktualisieren der einzelnen Pakete machbar.

Seit Beta 3 kann ich das Update einfach fortsetzen, bereits heruntergeladene Pakete werden wiederverwendet. Achtung Anzeigefehler: Es sieht weiterhin so aus, als müsste alles erneut heruntergeladen werden. Die Pakete tauchen immer wieder in der Liste der Pakete zum Herunterladen auf, bis die Aktualisierung komplett abgeschlossen ist.

Erfreulich ist auch, dass der Trend zu mehr Datenschutz inzwischen auch bei Haiku angekommen ist. Keine Sorge, Telemetriefunktionen hatte das System nie, in WebPositive gab es mit Google als Suchmaschine aber eine sehr fragwürdige Voreinstellung und diese musste durch Änderung der URL umgestellt werden. In Beta 3 ist DuckDuckGo Standard und die Suchmaschine kann aus einer Liste ausgewählt werden, in der Qwant und Ecosia weitere erfreuliche Optionen darstellen, neben den üblichen Datenkraken wie Google, Bing und Yahoo.

Auch Retro-Fans können sich über Beta 3 freuen: Wem das normale Haiku Interface noch nicht Retro genug aussieht, der kann das haiku_extras Paket aus dem HaikuDepot installieren und in den "Erscheinungsbild" Einstellungen den ControlLook auf Be umstellen. Nach einem Neustart hat Haiku nun das originale Aussehen seines Vorgängers. Das haiku_extras Paket ist nicht neu, doch in Beta 2 hatte die Umstellung auf den Be ControlLook nur minimale Auswirkungen. Hinweis: Der Be ControlLook funktioniert nur mit nativen Haiku Programmen. Das Aussehen von Qt Programmen verändert sich nicht.

Fazit: Mir gefällt es. Beta 3 ist ein weiterer wichtiger Schritt in Richtung Massentauglichkeit. Haiku eignet sich schon lange für alle Alltagsaufgaben, doch die Computerwelt entwickelt sich schnell weiter. Haiku nimmt das Wichtigste mit, gerade auch mit Blick auf bessere Hardwareunterstützung und moderneres WebKit, aber rennt auch nicht blind jedem fragwürdigen Trend hinterher.

Haiku Installieren: 32Bit x86 Download | 64Bit x86_64 Download | Installationsanleitung

Mo, 30. August 2021, Ralf Hersel

LibreELEC (kurz für Libre Embedded Linux Entertainment Center) ist ein nicht-kommerzieller Fork von OpenELEC, eine Distribution für den Kodi Media Player und Entertainment-Software. Die neue Version LibreELEC 10 bringt Kodi 19 "Matrix" zu den LibreELEC-Nutzern und bietet besserer Unterstützung für Raspberry Pi 4-Geräte, unterstützt HDMI-Ausgang bis zu 4Kp30, HDR-Ausgang (HDR10 und HLG), HD-Audio-Passthrough (Dolby TrueHD und DTS HD) sowie H264 und H265 Hardware-Decodierung.

Allerdings gibt es immer noch viele Blocker, die ein perfektes LibreELEC-Erlebnis auf dem Raspberry Pi 4 SBC verhindern. Zum Beispiel gibt es kein Deinterlacing mit den Hardware-Videodecodern, die 10-Bit- und 12-Bit-Videoausgabe ist nicht implementiert, und das Hyperion-Add-on funktioniert nicht mehr, da es den neuen Grafiktreiber-Stack nicht unterstützt.

Die Distribution kann von hier heruntergeladen und installiert werden.

Quelle: https://libreelec.tv/2021/08/26/libreelec-matrix-10-0/

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

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

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

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

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

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

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

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

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

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

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

Was habe ich mit Containern zu tun?

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

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

Wie lautet das Versprechen der Container-Technologie?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Wo ist nun das Dilemma?

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

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

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

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

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

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

Bis bald im schönen neuen Container-Land.

Problem

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

Hardware

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

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

Magic Lantern

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

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

Einschränkungen

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

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

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

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

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

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

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

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

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

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

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

Repo hinzufuegen

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

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

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

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

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

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

# Passwort besorgen 

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

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

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

Anwendung loeschen

microk8s.helm3 uninstall loki  -n monitoring

Anwendungskonfiguration als Yaml File

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

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

values.yaml

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

Nun den Stack erneut installieren

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

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

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

Die Standard-Kommandozeile Bash bei Kubuntu (wie auch bei vielen anderen Linux Distributionen) hat eine sehr praktische History bzw ein Verlauf, welche Befehle man so eingegeben hat.

Die entsprechende Datei heisst .bash_history (mit einem vorangehenen Punkt - weil es sich um eine versteckte Datei handelt) liegt im Benutzerverzeichnis z.B. /home/hoergen/.bash_history

Die gesamte History (Verlauf) auflisten mit dem Befehl: history
Dann wird ein Liste der Eingaben mit vorangestellter Zeilennummer ausgegeben.

Das können unter Umständen sehr viele Zeilen sein. Wenn man nach dem Befehl eine Zahl angibt, so werden die letzten Zeilen der History (Verlaufs) angezeigt wie z.B. history 8 zeigt die letzten 8 Zeilen der History an.

Damit man z.B. den Befehl aus der gefundenen Zeile nicht nocheinmal eingeben muss, kann man zur Abkürzung die Zeilennummer mit einem vorangestellten Ausrufezeichen verwenden z.B. !1500

In der History kann auch gesucht werden

• Suchen - Strg+r - und anfangen zu tippen
• Weitersuchen - nochmal Strg+r drücken
• Zeile aus der Suche übernehmen und starten - Eingabe Taste drücken
• Zeile aus der Suche übernehmen und etwas ändern - Ende- oder Pfeil nach rechts Taste

Und zum Korrigieren sind diese Tastenkürzel hilfreich

• Will man die Zeile löschen und ist am Anfang der Zeile: Strg+k
• Will man die Zeile löschen und ist am Ende der Zeile: Strk+u
• Will man die zuvor gelöschte Zeile wieder herstellen: Strg+y
• Das nächste Wort löschen Alt+d
• Das vorherige Wort löschen Strg+w

In der Zeile bewegen

• Pos 1 oder Strg+a springt an den Zeilenanfang
• Ende oder Strg+e springt an das Zeilenende
• Alt+f springt ein Wort vorwärts (Forward)
• Alt+b springt ein Wort zurück (Back)

Es gibt noch wesentlich mehr Kürzel und Befehle, die sich mit der History der Bash beschäftigen. Was sind eure Highlights?