Seit ein paar Wochen bin ich Besitzer einer mechanischen Keychron K6-Tastatur. Diese habe ich mir primär aus zwei Gründen angeschafft:

1. Es sollte eine 65% Tastatur mit mechanischen Switches sein.
2. Die Tastatur sollte kabellos funktionieren, am besten per Bluetooth. Bluetooth vor allem deshalb, weil meine Logitech-Maus auch per Bluetooth gekoppelt ist.

Beides erfüllt die K6 perfekt. Man gewöhnt sich recht schnell an die kleine Größe und die fehlenden F-Tasten. Ein kleines Problem gibt es aber leider:

Die Tastatur funktioniert erst nach dem Laden des Bluetooth-Stacks, d.h. wenn man z.B. im Bootmenü (Grub2 oder Bootctl) einen anderen Kernel oder ein anderes Betriebssystem auswählen will, muss man ein USB-Kabel an die Tastatur anschließen.

Das war mir auf Dauer zu blöd und zu unelegant. Es gäbe grundsätzlich noch die Möglichkeit einen HID-Proxy-fähigen USB-Bluetooth-Dongle einzusetzen, aber leider will die K6 nicht mit dem angeschafften Dongle koppeln. An Selbstbau-HID-Proxies auf Basis eines Raspberry PI-Zeros habe ich erst mal verzichtet.

Die Idee

Eigentlich bräuchte ich nur ein kleines Keypad, welches die Cursor-Tasten und eine Enter-Taste enthält. Keypads mit einem Ziffernblock gibt es wie Sand am Meer zu kaufen und auch programmierbare Keypads gibt es ein paar auf dem Markt. Ersteres war mir aber zu groß und nicht nerdig genug, letzteres viel zu teuer!

Also musste eine Selbstlösung her:

Diese sollte die genannten fünf Tasten plus noch eine Zusatztaste (Escape) enthalten um ein 3×2 Layout zu erhalten und um das Bootmenü und auch das BIOS mit diesem Keypad vollständig steuern zu können.

Alles was ich dazu benötigte, waren sechs Tasten (Switches), Tastenkappen (Keycaps=, eine passende Platine für die Tasten und einen Mikrocontroller, der als HID-Gerät (Sprich Tastatur) arbeiten kann.

Die Bauteile

Hier mal die Liste der Bauteile in Reihenfolge der Schwierigkeit ihrer Beschaffung:

1. Arduino Pro Micro: Grundsätzlich überall für ~11€ kaufbar. Mein Arbeitskollege Lukas hatte noch einen zu Hause rumliegen und hat ihn mir geschenkt (Danke nochmals dafür 😁). Dieser basiert auf dem ATmega32U4, welcher den HID-Modus bereitstellen kann.
2. Zehn Cherry-MX-kompatible Switches von einem No-Name-Hersteller über Amazon. Kostenpunkt ~1€ pro Switch.
3. Zehn symmetrische schwarze Keycaps ohne Beschriftung. Diese zu finden hat mich einen ganzen Abend gekostet! Wäre ich mehr in der Makerszene drin, hätte ich sie in zwei Minuten gefunden (Siehe 4.)
4. Breakout-Boards für die Switches. Diese gibt es in Deutschland z.B. bei Berrybase zu kaufen (Wie auch die Switches und die Keycaps, was ich aber zu spät gemerkt habe).

Da ich zuerst vorhatte das ganze erst einmal Prototyp-mäßig über ein Breadboard zu stecken, habe ich nicht direkt nach solchen Platinchen gesucht und erst einmal die Switches und die Keycaps bestellt. Da aber die Switches sich nur sehr schlecht auf einem Breadboard befestigen lassen, habe ich schnell nach passenden Platinen für die Switches gesucht.

Mehr Teile sind für den Aufbau eines Keypads nicht notwendig. Auf Pullupwiderstände kann man verzichten. Auf LEDs, für meinen Teil, auch.

Der Aufbau

Im Grunde ist der Aufbau sehr einfach:

Man verbindet die Breakout-Boards miteinander, indem man jeweils die 2er und 1er Lötpunkte verbindet. Um mehr Stabilität zu erhalten habe ich noch zusätzlich die Lötpunkte für die LEDs miteinander verbinden (+ und – auf den Breakoutboards). Um mir das Löten einfacher zu machen, habe ich die Platinen vor dem Löten mit Sekundenkleber zusammengeklebt. Das machte am Ende die Lötarbeiten viel einfacher. Danach habe ich die Kabel eingelötet. Das kann man 100% noch schöner machen, aber da das Keypad am Ende eh in ein kleines Gehäuse kommt, spielt das erst mal keine Rolle.

Am Ende habe ich dann noch die Switches eingelötet (Es kam ebenfalls Sekundenkleber als Löthilfe zum Einsatz). Auf den Arduino wird dann ein kleines installiert Sketch und fertig.

Leider habe ich keine Bilder vom Aufbau des Keypads gemacht, deshalb hier an dieser Stelle nur Bilder des fertigen Aufbaus:

• 

• 

Der Sketch ist dann auch ziemlich minimal:

#include <Keypad.h>
#include <Keyboard.h>

const byte rows = 3;
const byte columns = 2;

byte keys[rows][columns] = {
    {0xb0, 0xd7}, // Enter, Key right
    {0xda, 0xd9}, // Key up, Key down 
    {0xb1, 0xd8}  // Escape, Key left
};

byte rowPins[rows] = {3, 4, 5};
byte columnPins[columns] = {2, 9};
Keypad keypad = Keypad(makeKeymap(keys), rowPins, columnPins, rows, columns);

void setup() {
  pinMode(LED_BUILTIN_TX,INPUT); // Disable TX-LED
  pinMode(LED_BUILTIN_RX,INPUT); // Disable RX-LED
  Keyboard.begin();
}


void loop() {
  char key = keypad.waitForKey();

   if (key != NO_KEY){
    Keyboard.write(key);
  }
}

Man benötigt nur die beiden folgenden Libraries:

• Die Keyboard-Library: https://www.arduino.cc/reference/en/language/functions/usb/keyboard/
• Die Keypad-Library: https://playground.arduino.cc/Code/Keypad/

Danach funktioniert das Selbstbau-Keypad vollkommen fehlerfrei. Die einzige Einschränkung ist, dass es keine Tastenwiederholung gibt (Man muss die Taste loslassen und neu betätigen). Aber das spielt bei der Funktion, für die ich das Pad gebaut habe, keine Rolle.

Hier im Blog spreche ich mich immer wieder für Produkte bzw. Betriebssysteme von Apple aus und bekomme dafür ebenso oft Kritik. Meiner Meinung nach ist jedoch Perfektion der Feind des Guten und auch kleine Fortschritten lohnen sich.

Desktop und Smartphone sind nicht alles

Zuerst einmal lohnt es sich mal einen Schritt zurück zu machen und den ganzen Komplex Betriebssysteme, Smartphone und Desktop von seinem Sockel runter zu nehmen. Datenschützer schreiben gerne über den Komplex, weil man hier was tun kann und kehren alle anderen Bereiche unter den Teppich. Gedanken zu dieser Selbstermächtigung im Angesicht der Ohnmacht hatte ich vor einiger Zeit schon mal was geschrieben.

Auf konkretes Beispiel heruntergebrochen: Du kannst ein super gehärtetes System mit Coreboot und FreeBSD nutzen und vielleicht ein Purism Librem 5 als Smartphone (ich übertreibe jetzt absichtlich). Wenn du dann vor die Tür gehst und in deinen Tesla oder ein anderes modernes Auto steigst, ist dein persönlicher Datenschutzniveau bereits völlig im Eimer – um es mal umgangssprachlich auszudrücken. Und hier haben wir noch nicht mal von Konzepten wie beispielsweise der elektronischen Patientenakte gesprochen, die sich völlig der Kontrolle des Einzelnen entzieht. Ganz zu schweigen davon, dass man natürlich an keinem Bonusprogramm wie payback & Co partizipiert. Mit Kredit/Debitkarte zahlt man natürlich auch nicht. Und man schließt besser auch keine Verträge mit Schufa-Überprüfung. Unter der Brücke, soll es sich ganz gut leben lassen, hab ich gehört. Hauptsache der Datenschutz ist gewahrt! Allerdings natürlich nur wenn man ein blickdichtes Zelt hat.

Das bedeutet jetzt nicht, dass man im Bereich der eigenen Geräte nichts machen sollte, aber vielen Leuten würde es guttun, von ihrem Sockel herunterzusteigen. Die vermeintlichen Lichtgestalten strahlen außerhalb ihrer Selbstdarstellung meist gar nicht so hell. Datenschutz im Alltag ist viel mehr und gemessen am großen Ganzen wiegen die Fortschritte im digitalen Bereich vielleicht gar nicht so schwer.

Ausgangsniveau beachten

Maßnahmen muss man auf Basis des Ausgangsniveaus der meisten Menschen bewerten. Ausgehend von den Marktanteilen nutzt der durchschnittliche Anwender ein Notebook mit Windows 10 und ein Android-Smartphone. Bei den mobilen Begleitern sind das ausweislich der Zahlen meist ein Budget-Modell von Samsung oder ein Gerät von Xiaomi. Huawei hat zuletzt Marktanteile eingebüßt.

Diese Hardware/Betriebssystem-Ausgangsbasis ist dann mit zahllosen wenig Datenschutz-freundlichen Diensten angereichert. E-Mail-Konten aus dem United Internet-Universum, Cloudspeicher bei einem der großen amerikanischen Unternehmen, Stream für Musik und Serien/Filme usw. usf. Vielleicht auch bereits erste Anleihen am Smart Home-Trend, smarte Lautsprecher und smarte Fernseher. Natürlich mit Rundumüberwachung.

Kleine Schritte, große Wirkung

Bei dieser Ausgangslage können bereits kleine Schritte viel Effekt erzeugen. Mal die Einstellungen auf dem Smartphone durchgehen, den ein oder anderen Dienst, den man nicht braucht abbestellen oder durch eine Datenschutz-freundlichere Alternative ersetzen. Gerade am Anfang ist das Optimierungspotenzial noch gewaltig, ohne gleich den Vorschlaghammer zu benötigen, der den kompletten eigenen Hardwarebestand zertrümmert. Die eigene Hardware kommt dann erst in einem weiteren Schritt dran, vielleicht beim nächsten Erneuerungszyklus, wenn auch aus Gründen des Datenschutz ein anders Gerät von einem besseren Hersteller gewählt wird.

Genau an diesem Punkt kommt für mich auch die Empfehlung für ein MacBook, iPhone & Co. Gemessen an der Datenerhebung von Microsoft und den massiven Datenabflüssen zu Google und nach China bei handelsüblichen Android-Smartphones, bietet Apple einen substanziellen Fortschritt. Keine Perfektion, denn auch bei Apple ist beim Datenschutz noch viel Luft nach oben, aber ein Grundverständnis für Privatsphäre und Datenschutz gibt es zumindest in Teilen des Unternehmens und keine enge Verquickung mit der Werbebranche. Ein „dummer“ Fernseher mit einem Apple TV ist im Zweifelsfall eben doch Datenschutz-freundlicher als ein smarter Xiaomi-TV.

Die stetig steigenden Marktanteile des iPhones in Deutschland sind somit eine gute Entwicklung für das allgemeine Datenschutz-Niveau, zumindest bezüglich der Endgeräte und Dienste.

Kein Datenschutz ohne freie Software?

Der Ruf nach freier Software bzw. die Gleichsetzung von Open Source und Privacy hat sich inzwischen in vielen Köpfen verankert. Ohne Linux kann es bei vielen Kommentatoren keinen Datenschutz geben. Dadurch schirt sich eine exklusive Gruppe nach außen ab und alle anderen können sowieso keinen Datenschutz erreichen.

Das sehe ich nicht so. Erstens hängt das von der Art ab, wie man Linux nutzt und zweitens halte ich reale Fortschritte für wichtiger als für viele unerreichbare ideale Fernziele. Für diese harten Aussagen gibt es mutmaßlich wieder empörte Kommentare, aber so ist das halt. Linux wird auf dem Desktop in der bisherigen Form keine substanzielle Position mehr einnehmen, der Zug ist abgefahren. Das aktuelle Niveau mag man halten, aber mehr auch nicht. Eher glaube ich noch an steigende Marktanteile von macOS im Desktopsegment und das wäre bei richtiger Konfiguration für den Datenschutz nicht so viel schlechter als ein Linux-System

Die Linux-Community hat schon vor längerer Zeit den Versuch aufgegeben, auf dem Desktop eine gleichwertige Alternative zu macOS oder Windows anzubieten. Ungefähr zu jenem Zeitpunkt, als Canonical seine Investition in den Ubuntu-Desktop massiv zurückfuhr. Stattdessen hat man sich in der Nische eingerichtet, bedient die Bedürfnisse einer hochgradig spezialisierten Community, führt lächerliche Grabenkämpfe und feiert das als Stärke von freier Software.

Im mobilen Bereich ist man sogar von diesem erbarmungswürdigen Niveau noch Jahre entfernt und freut sich schon, wenn das Gerät mit freier Software startfähig ist und rudimentäre Funktionen bietet. Andere Bereiche hat die Community noch nicht mal in den Blick genommen, weil die Kriege von gestern zu viel Ressourcen binden, um in die Zukunft zu schauen.

Es ist daher vollkommen fehlgeleitet, Anwender auf den Linux-Pfad zu zwingen, wenn sie „nur“ etwas für den Datenschutz tun wollen. Da gibt es leichtere, sinnvollere und zukunftsfähige Alternativen. Diese werde ich hier weiter empfehlen, denn diese Seite hat den Anspruch praktische Hilfestellung für digitalen Selbstdatenschutz zu vermitteln und nicht die reine Lehre zu predigen, die dann trotzem niemand umsetzt.

Schlussfolgerung

Wenn man mit Linux arbeiten kann und möchte, ist das natürlich noch besser, als wenn man macOS nutzt, wenn man Lust hat, sich mit Custom ROMs zu befassen, ist Android besser als iOS. Wenn man das aber zum alleinseeligmachenden Anspruch erhebt, dann haben in diesem Land <5% der Nutzer eine Chance auf wirksamen Datenschutz.

Hier sollte man hinterfragen, ob das wirklich faktengestützt ist oder nur der Selbstdarstellung einer kleinen Minderheit dient, die für ihre Leidensfähigkeit belohnt werden möchte.

Dazu möchte ich ein kleines Bild bemühen. Wenn man sich Datenschutz im digitalen (!) Alltag im Bereich der Endgeräte als Skala von 1 bis 100 vorstellt, wobei „1=Windows/Stock-Android+Crap-Dienste“ und „100=gehärtete Linux+GrapheneOS+selbstgehostete Dienste“, dann kommt man mit macOS/iOS und so Diensten wie Posteo vielleicht schon in Richung von 70-80 Punkte. Hier darf durchaus hinterfragt werden, ob die Entbehrungen für die letzten Meter noch einen nennenswerten Ertrag bringen. Das Paretoprinzip lässt hier freundlich grüßen.

Für die große Mehrheit ist ein Wechsel auf macOS/iOS schon ein Fortschritt für den persönlichen Datenschutz und dieser Fortschritt ist realistischer als ein verbreiteter Einsatz von Linux.

Zumal – und das führt an den Anfang des Artikels zurück – Desktopbetriebssysteme und Smartphones nur ein sehr kleiner Baustein sind und nur, weil man hier verhältnismäßig viel Einfluss nehmen kann, sollte man nicht dem Glauben verfallen, hier auch einen großen Effekt zu haben. Ob man hier nun ein zu 80 % oder 100 % perfektes System hat, ist auch schon wieder nicht mehr so wichtig, wenn der Rest nicht auch perfekt ist – und das ist er bei niemandem.

Der Artikel Kommentar: Datenschutz im Alltag – Auch kleine Schritte lohnen erschien zuerst auf [Mer]Curius

elementaryOS verfügt über eine Status- und Menüleiste, ähnlich macOS. In dieser Leiste, welche sich am oberen Bildschirmrand befindet, befinden sich Indikatoren für das Netzwerk, den Sound und einige andere Dinge. Auch Applikationen, wie z. B. der Nextcloud-Client legen dort ihr Status-Icon ab. Wenn der Nextcloud-Client unter elementaryOS in der Version 6 (Odin) installiert wird, taucht allerdings kein Icon in der oberen Leiste auf. Grund hierfür ist das diese nicht Out-of-the-box unterstützt wird.

Allerdings kann hier Abhilfe geschaffen werden mit dem Wingpanel Ayatana-Compatibility Indicator. Um diesen in elementaryOS zu installieren, sollte im ersten Schritt das Terminal geöffnet und einige Abhängigkeiten installiert werden:

install libglib2.0-dev libgranite-dev libindicator3-dev libwingpanel-dev indicator-application

Anschließend kann der Download der entsprechenden DEB-Datei angestoßen werden:

wget -c "https://github.com/Lafydev/wingpanel-indicator-ayatana/blob/master/com.github.lafydev.wingpanel-indicator-ayatana_2.0.7_amd64.deb?raw=true" -O wingpanel-indicator.deb

Danach wird das heruntergeladene Paket installiert:

dpkg -i wingpanel-indicator.deb

Nun muss dafür gesorgt werden, dass der Wingpanel Ayatana-Compatibility Indicator beim Systemstart geladen wird. Dies kann unter elementaryOS über die Systemeinstellungen und dort den Punkt Anwendungen bewerkstelligt werden. Dort findet sich der Punkt Beim Anmelden automatisch gestartete Anwendungen. Unter diesem Punkt wird nun unten links eine neue Anwendung hinzugefügt und dort ein benutzerdefinierter Befehl eingegeben:

/usr/lib/x86_64-linux-gnu/indicator-application/indicator-application-service

Im Terminal muss nun noch eine Änderung an der Datei indicator-application.desktop vorgenommen werden:

nano /etc/xdg/autostart/indicator-application.desktop

Dort muss nun der Parameter Pantheon; hinzugefügt werden, sodass die Datei am Ende wie folgt aussieht:

[Desktop Entry]
Type=Application
Name=Indicator Application
Exec=/usr/lib/x86_64-linux-gnu/indicator-application/indicator-application-service
StartupNotify=false
Terminal=false
OnlyShowIn=Unity;GNOME;Pantheon;
NotShowIn=ubuntu;
NoDisplay=true
AutostartCondition=GNOME3 unless-session gnome

Nach einem Neustart des Systems funktioniert der neue Indikator, sodass z. B. das Status-Icon des Nextcloud-Clients ebenfalls auftauchen sollte.

Was Linux-Distributionen angeht, bin ich ein Freund von elementaryOS. Vor einiger Zeit hatte ich diese Distributionen auf einem älteren Laptop installiert. Die Festplattenverschlüsselung wurde bei der Installation aktiviert. Beim Hochfahren erschien nun allerdings keine Aufforderung zur Eingabe des Passwortes. Stattdessen blieb der Bildschirm dunkel.

Nach einem erzwungenen Neustart, erscheint dann das GRUB-Bootmenü und nach dem Start der elemantaryOS-Installation erscheint die Passworteingabe im Textmodus. Behoben werden kann diese Verhalten durch eine Änderung der GRUB-Konfiguration:

nano /etc/default/grub

Der Datei sollte nun folgende Zeile hinzugefügt werden:

GRUB_GFXPAYLOAD_LINUX=text

Nach dem Speichern der Datei muss die Konfiguration und mit ihr der Bootloader noch aktualisiert werden:

update-grub

Damit wird beim Start des Linux-Kernels der Textmodus erzwungen und somit sollte die Passworteingabe immer zu sehen sein.

Google hat mit dem Pixel 6 und dem Bose-Deal ein gutes Angebot vorlegt. Zumal dafür mittelfristig GrapheneOS lauffähig sein wird und so manche Querelen mit normalem LineageOS damit der Vergangenheit angehören werden. Bis dahin liegt das Gerät in der Schublade.

Allerdings wollte ich noch kurz die Funktionsfähigkeit testen und habe das Gerät eingeschaltet, die Einrichtungsroutine durchlaufen, kein Google-Konto hinterlegt und lediglich mit dem Gast-WLAN verbunden. Dann habe ich interessehalber Blokada installiert und das Gerät ein paar Stunden liegen gelassen.

Das Ergebnis sieht so aus:

Viele, viele Verbindungen zu allen möglichen Google-Diensten. Viele davon werden mindestens stündlich aktiviert, manche nur beim Aufwecken des Gerätes (die 14-15 Sekunden vorher erfolgte Verbindung). Wie gesagt: Ohne weitergehende Interaktion mit dem Gerät, ohne irgendwelche der Apps zu öffnen.

Das gesamte Portfolio von Play-Store über AdService und die wichtige Werbeplattfom Doubleclick. Eine tiefer gehende Analyse des Datensendeverhaltens ist das jetzt nicht, deshalb sind die Ursache der Abfrage und die mit ihnen übertragenen Metadaten nicht klar, aber vermutlich wird das Übliche an Informationen bei den Verbindungen mit übertragen, um einen digitalen Fingerabdruck zu erzeugen.

Kaum eine dieser Abfragen ist wirklich notwendig. Mein LineageOS-System benötigt keine davon und der Updatecheck und die Push Notifications über die Play Services reichen als Erklärung/Rechtfertigung garantiert nicht aus.

Man muss es so deutlich sagen: Bei diesem Datensendeverhalten kann sich Google noch so sehr um Privacywashing bemühen – der Datenschutz ist eine Katastrophe. Nur schade, dass die Berichterstattung immer darauf anspringt. Gerne natürlich von Bloggern und Newsseiten mit vielen Anzeigen und Analysewerkzeugen von Google. Eigentlich müsste da unter jeden Artikel ein Transparenzvermerk über mögliche Interessenkonflikte stehen.

Dabei ist ein Google Pixel im Android-Ökosystem sogar noch die bessere Alternative, weil wenigstens nur Daten an Google fließen und nicht noch an ein weiteres Unternehmen wie Samsung oder mittelbar an einen totalitären Überwachungsstaat (Xiaomi, Huawei etc.)

Datenschutz und Googles Android sind zwei unvereinbare Begriffe. Android ist nur dann eine Option, wenn man das Knowhow und die Zeit hat, sich mit alternativen ROMs zu beschäftigen, sowie eher unterdurchschnittliche Erwartungen an Apps hat und diese dann über F-Droid bezieht. Alle anderen weichen besser auf einen Hersteller aus, der seinen Umsatz nicht mit Werbung und damit faktisch auch User-Tracking generiert. Leider ist das momentan einzig und allein Apple.

Der Artikel Google Pixel 6 – Keine Aktivität, viele Anfragen erschien zuerst auf [Mer]Curius

Fr, 12. November 2021, Lioh Möller

Unmittelbar nach der Veröffentlichung der neuen Red Hat Enterprise Linux Version 8.5 steht eine aktualisierte Version von AlmaLinux zur Verfügung. Die Geschwindigkeit, mit der diese bereitgestellt wurde, stellt eine herausragende Leistung des Projektes dar.

Neben neuen Versionen für die x86_64 und ARM Architekturen werden Images für den Raspberry Pi angeboten.

Die Live ISOs sowie die Abbilder für die Cloud und Containernutzung werden in Kürze nachgeliefert. Das AlmaLinux bedankt sich in der Ankündigung ausdrücklich beim CentOS Projekt und läutet eine neue Ära der RHEL-Clones ein.

AlmaLinux möchte auch in Zukunft mit CentOS Stream zusammenarbeiten, um so einen bestmöglichen Nutzen für die Anwender beider Distributionen zu bieten.

In der aktuellen Version wurden unter anderem die Container Tools verbessert und OpenJDK 17 integriert. Darüber hinaus wurde Network Time Security (NTS) zur Erhöhung der Sicherheit von NTP implementiert. Eine ausführliche Liste aller Änderungen finden sich in den Release Notes.

Quelle: https://almalinux.org/blog/almalinux-os-85-stable-now-available/

Download: https://mirrors.almalinux.org/isos

Fr, 12. November 2021, @65536@troet.cafe

NixOS ist eine Linuxdistribution, die viele Dinge bei der Systemverwaltung anders handhabt als die meisten anderen Distributionen. Wie es funktioniert und weshalb es anders gemacht wird, darum soll es in dieser Artikelserie gehen.
Im ersten Teil wird es einen Überblick über die Ideen, die hinter NixOS stehen, geben. Im zweiten werden die Installation und grundlegende Konfiguration behandelt, und der dritte Teil befasst sich mit Details der Softwareverwaltung. Im vierten Teil folgen ein paar Empfehlungen und sonstige Details.

Imperativ

Klassischerweise wird Linux zu grossen Teilen imperativ verwaltet. Das bedeutet, einzelne Befehle werden nacheinander angewandt, um das System Schritt für Schritt in den gewünschten Zustand zu bringen. NixOS erlaubt zwar diesen imperativen Ansatz, versucht jedoch, soweit irgend möglich, stattdessen deklaratives Verwalten anzubieten.

Der Grund dafür ist die mangelnde Reproduzierbarkeit beim imperativen Ansatz. Zwei Instanzen eines Betriebssystems unterscheiden sich in der Regel, weil sie unterschiedliche Vergangenheiten haben. Vielleicht wurde auf einem System eine Software getestet, auf dem anderen jedoch nicht. Auch nach Deinstallation hinterliess es Spuren auf dem ersten. Vielleicht wurde Software in unterschiedlichen Abständen aktualisiert, oder in unterschiedlichen Versionen erstmals installiert, weshalb kleine Unterschiede auftreten.

Selbst wenn man sich bemüht, mehrere Betriebssysteminstanzen immer gleich zu verwalten, werden sich durch kleine Zufälle und Versehen die Unterschiede anhäufen, bis auf einem System ein Befehl gelingt und auf dem anderen scheitert, und man sich fragt, warum.

Deklarativ

NixOS wurde konzipiert in der Bemühung, möglichst viele Dinge deklarativ konfigurieren zu können, sodass lange Zeit zurückliegende imperative Befehle keinen Einfluss darauf haben, was man jetzt erreichen will. Hierzu wird eine in /etc/nixos/ abgelegte Datei configuration.nix bearbeitet. In der nix-eigenen Syntax lassen sich die gewünschten Pakete angeben, zahlreiche Optionen von der Zeitzone über automatische Updates bis hin zu Benutzereinstellungen deklarieren und bei Bedarf weitere Konfigurationsdateien mit mehr Details einbinden.

Mit einem einzigen Befehl kann dann - nach jeder Änderung der Konfigurationsdatei - diese auf das komplette System angewandt werden, wahlweise bei Neustart oder - soweit ohne diesen möglich - sofort. Jede solche Neukonfiguration sowie jedes Systemupdate erzeugt einen neuen Booteintrag, was bei Problemen und Fehlkonfigurationen Rollbacks sehr leicht macht.

Anstatt sein System mit Einzelbefehlen kontinuierlich umzuformen, hat man nun eine Datei als Bauanleitung, die knapp und deutlich definiert, wie das System auszusehen hat.

Reproduzierbar

Ein resultierender grosser Vorteil ist die Reproduzierbarkeit. Stattet man mehrere Rechner mit derselben Konfiguration aus, so gilt diese für alle. Andernfalls müssten eine ganze Reihe an Befehlen zum Einrichten eines Programms oder zum Setzen bestimmter Einstellungen auf sämtlichen Rechnern jeweils identisch durchgeführt werden, was wesentlich fehleranfälliger ist.

Auch für einzeln zu verwaltende Rechner ist die Reproduzierbarkeit nützlich. Um sein System wiederherzustellen oder um einen neuen Rechner einzurichten, braucht es weder ein vollständiges Backup der Festplatte noch eine Liste aller bislang vorgenommenen Installationen von Software. Das Sichern und Einfügen der Konfigurationsdatei reicht, was Speicherplatz im Backup und Zeit bei der Einrichtung spart.

Lediglich die hardwarespezifischen Konfigurationsteile könnten eine Änderung benötigen.

Funktional

Damit die Konfiguration wirklich reproduzierbar angewandt werden kann, muss ein funktionaler Paketmanager eingesetzt werden. Dieser wird Nix genannt. Um zu garantieren, dass das Installieren eines Paketes überall dasselbe Resultat bewirkt, werden alle Abhängigkeiten unabhängig von bereits installierter Software berechnet und alles unter /nix/store/ installiert, in einem Ordner mit einem Hashwert als Präfix. Der Hashwert ändert sich, wenn das Paket in irgendeiner Weise anders erstellt und installiert wird, im einfachsten Fall bei einer Versionsänderung. Nix ist rein funktional: die Installation desselben Paketes in derselben Version resultiert immer in einem identischen Eintrag im Nix-Store, unabhängig von jeder Eigenschaft der NixOS-Instanz.

Unkonventionell

All diese Eigenschaften zu haben, bedeutet für NixOS, in einigen Dingen ungewöhnliche Wege gehen zu müssen. Insbesondere sind zahlreiche Ordner und Dateien nicht dort, wo sie üblicherweise zu erwarten sind, sondern sind Verknüpfungen auf den Nix-Store. Die Tatsache, dass zum Systemstart lediglich /nix/ und /boot/ zwingend nötig sind, erlaubt auch interessante Ansätze, um Systemzustand noch weiter zu verringern.

Wie oben erwähnt soll im weiteren Verlauf der Artikelserie konkreter auf die Handhabung von NixOS eingegangen werden. Von all den Möglichkeiten und Werkzeugen wird allerdings nur an der Oberfläche gekratzt werden, um Interessierten den Einstieg in NixOS zu erleichtern.

Links

https://nixos.org/
https://nixos.wiki/

Do, 11. November 2021, Ralf Hersel

In der Vergangenheit finden sich einige Beispiele dafür, wie sich 'übermotivierte' Projekte vom Community-Geist verabschiedet haben. Da wäre zum Beispiel die Firma Canonical, die sich mit vielen Ideen (TV, Smartphone, MIR, Unity, Snap-Paketen) vom Rest der freien Gesellschaft abheben wollte, letztendlich aber damit gescheitert ist. Oder Tuxedo-Computers, die mit TUXEDO-OS (einem Ubuntu-Derivat) einen eigenen Weg beschritten sind.

Eine ähnliche Richtung schlägt nun auch der Geräte- und Distro-Hersteller System76 ein. Wir berichteten darüber, dass die Firma demnächst GNOME links liegen lässt, um einen eigenen Desktop (COSMIC) zu entwickeln. In den letzten Tagen hat sich das Verhältnis zwischen System76 und dem GNOME-Team weiter abgekühlt, was sich in einem Blog-Post des GNOME-Designers Chris Davis manifestiert.

Als Einleitung schreibt er:

In letzter Zeit gab es einige hitzige Diskussionen über die Zukunft von GNOME. Dies hat dazu geführt, dass eine Menge Angst, Unsicherheit und Zweifel über GNOME verbreitet wurden, sowie Angriffe und Feindseligkeit gegenüber GNOME als Ganzes und gegenüber einzelnen Mitwirkenden. Dies begann grösstenteils aufgrund der Äusserungen von Mitarbeitern der Firma System76.

Einer der Streitpunkte ist der Linux Vendor Firmware Service (LVFS). In den Jahren 2017 und 2018 kommunizierte Richard Hughes, dass man für Firmware Updates LVFS einsetzen wolle. Dann kündigte System76 plötzlich seine eigene Infrastruktur und Software für Firmware-Updates an.

Weiter ging es mit der Behandlung von Patches. Im Jahr 2019 teilte Sebastien Bacher von Canonical einen Beitrag über den Umgang mit Fehlerbehebungen gegenüber Upstream durch System76. Dieses Verhalten betraf sowohl Ubuntu als auch GNOME. System76 hat Fehler, die für Pop!_OS relevant waren, behoben, jedoch nicht an Upstream geliefert:

"Später fingen sie an, die Upstream (Ubuntu, GNOME, ...) Bug Tracker zu kommentieren und weisen die Benutzer darauf hin, dass das Problem in Pop!_OS behoben wurde, und werben damit, dass sie sich um die Benutzer kümmern und das Problem bei sich behoben haben. Sie sollten zwar stolz auf die Arbeit sein, die sie für Ihre Benutzer leisten, aber ich denke, sie gehen hier den falschen Weg. An Korrekturen zu arbeiten und sie früh in das Produkt einzubauen ist eine Sache, diese Korrekturen nicht in an Upstream zu geben, um sich besser vermarkten zu können, ist ein riskantes Spiel", so Sebastien Bacher.

Dann kam System76 mit dem GNOME-Shell Tiling. Ende 2019 begann System76 mit der Arbeit an einer Erweiterung, die ein i3-ähnliches Tiling in GNOME ermöglichte. Als ein Upstream-Designer die Zusammenarbeit beim Tiling anbot, weigerte sich Jeremy Soller, leitender Ingenieur bei System76, mit ihm zu arbeiten. Der wirklich problematische Teil ist, dass System76 in den letzten Jahren immer wieder behauptet hat, dass Upstream nicht an Tiling interessiert sei, was laut Michael Murphy (GNOME) eine Falschaussage ist.

Kurz nachdem GNOME 40 bekannt gegeben hatten, überraschte Jeremy Soller mit der Aussage, dass System76 dem neuen Design der GNOME-Shell nicht zugestimmt habe. Er behauptete auch, dass das Feedback der Designerin nicht berücksichtigt wurde. Laut dem GNOME-Team ist das nicht der Fall. Tatsache sei, dass System76 für etwa ein Jahr des dreijährigen Entwurfsprozesses eine Designerin hinzugezogen hat. Die Designerin nahm an Design-Calls und Diskussionen mit dem Design-Team teil, und ihre Rolle konzentrierte sich auf die UX-Forschung selbst. Während des Designprozesses gab es nie Mockups oder konkrete Vorschläge von System76. Das einzige Mal, dass System76 einen Vorschlag gemacht habe, war ganz am Ende des Entwurfsprozesses bei einem Treffen des Entwurfsteams mit Interessengruppen. Dort stellten sie COSMIC vor und bekamen nicht das gewünschte Feedback.

Das Verhalten des Unternehmens wiederholte das ursprüngliche Muster. Als sich System76 mit seinem Entwurf nicht durchsetzen konnte, begann es, Fehlinformationen zu verbreiten. Dieser spezielle Fall von Fehlinformation war sehr schädlich für den Ruf von GNOME.

Die neueste Eskalation zwischen GNOME und System76 betrifft das Thema 'Gtk Themes und libadwaita'. Als Hintergrund-Information empfehle ich dieses Video von 'The Linux Experiment'. Die umfangreichen Details dazu erfahrt ihr im letzten Kapitel der Quelle.

Fazit

System76 gesellt sich zu den Projekten (Firmen), die Mühe mit der Balance zwischen eigenem Erfolgsbegehren und der Community-Zusammenarbeit haben. Exklusion und eigene Suppen kochen, haben in der Geschichte freier Software noch nie zum Erfolg geführt. Zusammenarbeit unter den Projekten und Upstream-Delivery sind bessere Rezepte um am gemeinsamen Ziel zu arbeiten. Die Firma System76 muss sich fragen lassen, ob ihr Verhalten nicht nur ein Lippenbekenntnis zu freier Software und der Community ist.

Quelle: https://blogs.gnome.org/christopherdavis/2021/11/10/system76-how-not-to-collaborate/

Do, 11. November 2021, Lioh Möller

Zwischen dem 7. und 29. Oktober hat das openSUSE Projekt Paketbetreuer befragt. Nun wurden die Ergebnisse veröffentlicht, welche einerseits erwartbar waren, aber dennoch ein Bild aufweisen, welches in den meisten Free Software Communitys vorzufinden ist.

So gaben 95% der Befragten an männlichen Geschlechts zu sein. Ein Grossteil der Paketbetreuer stammt aus Westeuropa. Nur 6% gaben an aus Amerika zu stammen. Weitere 6% finden sich im asiatischen Raum.

Fast 75% haben einen Universitätsabschluss oder studieren und 68.75% sind oder waren zuvor beruflich im IT-Umfeld tätig.

Als Kommunikationsmittel der Wahl wird weitestgehend auf Mailinglisten und IRC gesetzt. Matrix hingegen spielt bisher eine eher untergeordnete Rolle.

Es sind nahezu alle Altersgruppen vertreten, was aufzeigt, dass ein Projekt wie openSUSE durchaus auch für jüngere Beitragende interessant ist.

Die gesamten Ergebnisse der Umfrage, sowie einige persönliche Stellungnahmen der Befragten finden sich im Wiki

Mi, 10. Oktober 2021, Niklas

Es ist wieder so weit, das Haiku Projekt, ein freier Nachbau des alten BeOS Betriebssystems, berichtet über die Fortschritte in der Entwicklung. Beta 3 ist inzwischen erschienen und ein voller Erfolg. Trotzdem gibt es noch viel zu tun und das Projekt hat wieder beeindruckende Fortschritte gemacht.

Der Kernel wird jetzt immer mit GCC 8 kompiliert, auch auf 32 Bit Systemen. Bisher wurde GCC 2 benutzt, um die Kompatibilität zu BeOS Treibern zu erhalten, aber aufgrund von anderen Neuerungen wie SMAP, wodurch sich das ABI leicht änderte, haben diese ohnehin schon einige Zeit nicht mehr funktioniert. Da sich niemand beschwert hat, sieht das Projekt keinen Grund, die Treiberkompatibilität weiterhin zu behalten. Die Umstellung sorgt für Performanceverbesserungen auf 32 Bit Systemen, da GCC 8 den Code besser optimiert. Ausserdem können Kernelentwickler jetzt modernere C++ Funktionen verwenden.

Des Weiteren wurden Optimierungen am Syscall Entry und Exit vorgenommen. Hier enthielt der Assembler Code einige nutzlose Synchronisierungsinstruktionen, die nur für Hardware Interrupts und nicht für Syscalls gebraucht werden. Diese wurden entfernt.

Es wurden auch einige Anstrengungen unternommen, um das Haiku Hauptpaket zu verkleinern. Aus diesem Grund wurden Translators, Media Add-ons und WLAN Firmwares in eigene Pakete ausgelagert. Sie sind trotzdem noch vorinstalliert. Der Grund für die Änderung ist, dass das Hauptpaket deutlich öfter aktualisiert wird als diese Bestandteile und es ergibt wenig Sinn, die gleichbleibenden Teile jedes Mal neu herunterzuladen.

Das Flat Theme für Haiku, das bereits seit Juni 2020 in Arbeit ist, wurde jetzt zum haiku_extras Paket hinzugefügt. Es kann einfach über Haiku Depot installiert und dann in den Einstellungen aktiviert werden. Damit sieht Haiku deutlich moderner aus. Achtung: Nur für Nightly Nutzer! Beta 3 Nutzer erhalten das haiku_extras Update nicht bzw. erst mit der nächsten grossen Beta.

Im Repository mit den Haiku Build Paketen wurden libavif und ZSTD aktiviert. libavif wird fuer den AVIF Translator gebraucht, ZSTD soll in Zukunft für die HPKG Pakete zum Einsatz kommen und zlib ablösen. Es wird die Pakete kleiner und schneller machen. Ausserdem wurden die Paketinformationen vereinfacht, um zu vermeiden, dass manche Angaben für jede Architektur einzeln gemacht werden müssen.

Der Quellcode der Tools Container und ShelfInspector wurden in Haiku eingefügt. Diese ermöglichen das Testen von Replikanten, ohne sie auf dem Desktop einfügen zu müssen. Sie erscheinen dann in einem eigenen Fenster, was hilfreich beim Debugging ist. Es gab davon zu BeOS Zeiten schon einige Implementierungen, aber bisher war keine im Haiku Quellcode enthalten.

Die os-prober Scripts zum automatischen Erkennen und Hinzufügen von Haiku zu GRUB wurden ebenfalls mit aufgenommen. Vorher waren diese nur im Bug Tracker von Debian zu finden und wurden nicht gemerged. Man hofft, dass sie in die offiziellen os-prober Releases aufgenommen werden, wenn sie jetzt besser zu finden sind.

Auch an den Programmen wurde gearbeitet. In HaikuDepot wurde der Sprachfilter repariert, mit dem nur Review in Sprachen angezeigt werden, die der Nutzer versteht. Ausserdem wurde eine Spalte hinzugefügt, die anzeigt, wann ein Paket zuletzt aktualisiert wurde.

Im MediaPlayer wurde das Caching von Längen in der Playliste verbessert, wenn Dateisysteme verwendet werden, die diese Information nicht in den Dateiattributen speichern können. So kann man zum Beispiel auch auf read-only Dateisystemen ohne Verzögerung durch die Liste scrollen.

Die Hexadezimal-Ansicht in DiskProbe wurde optisch aufgewertet und stellt die Reihen jetzt unterschiedlich dar und hat vertikale Linien, damit man nicht so leicht durcheinander kommt. Das thttpd Server, der vom Poorman Webserver verwendet wird, wurde auf die neueste Version aktualisiert. HaikuWebKit wurde auch aktualisiert, was die Performance verbessert und einige Abstürze behebt.

Die Server und Bibliotheken wurden ebenfalls verbessert. app_server hat Unterstützung für die neu eingeführten RGB48 und RGBA64 Colorspaces bekommen. Ausserdem wurde die Verarbeitung von Clipping und Reverse Clipping verbessert.

Es wurden einige Funktionsanmerkungen hinzugefügt, um GCC mitzuteilen, dass manche Funktionen immer Pointer mit Vielfachen von 2 Bytes zurückgeben. GCC kann dadurch schnelleren Code generieren, zum Beispiel durch Verwendung von SSE2 Instruktionen, die diese Ausrichtung erfordern.

Einige fehlende POSIX Errors wurden zu Errors.h hinzugefügt. Der B_FILE_NOT_FOUND Error wurde aus dem Storage Kit entfernt. Er war schon in BeOS R5 als veraltet markiert und wurde durch den allgemeineren B_ENTRY_NOT_FOUND Errorcode ersetzt.

BMenu hat jetzt Methoden, um Einträge zu sortieren und tauschen, ohne sie zu löschen und neu zu erstellen. Das wird in der Liste der WLAN-Netzwerke genutzt. Vorher konnten Einträge gelöscht werden, als das Menü gerade offen war, was einen Absturz auslöste.

Ein paar spezielle Memory Copy Funktionen wurden aus dem app_server entfernt. Sie wurden als Workaround für Einschränkungen des AGP Bus eingeführt und werden nicht mehr gebraucht, weil die Implementierung von memcpy jetzt genauso gut funktioniert.

Folgende Verbesserungen wurden an den Treibern vorgenommen:

• Intel Grafiktreiber
  • Fehler bei Bildschirmschonern auf älterer Hardware behoben.
  • Bugfixes, wenn Programme ihr Bild am app_server vorbei direkt an den Treiber senden, zum Beispiel durch BWindowScreen.
  • Benutzerdefinierte Bildwiederholungsraten sind jetzt möglich.
  • Erlaubte Frequenzen wurden repariert (die Intel Dokumentation ist teilweise nicht korrekt, also werden jetzt die Informationen aus dem Linux Treiber benutzt).
  • Fortschritt bei der Unterstützung moderner Skylake und Haswell Chipsets.
• Fehler bei fragmentierten USB Transfers und Locking Probleme im XHCI Treiber behoben.
• NVMe Treiber verbessert, mit überarbeitetem Interrupt Handling, Optimierung der Transfers in bestimmten Situationen und besserer Verwendung mehrerer Threads. Das macht den Treiber schneller und mit mehr Hardware kompatibel.
• SMAP Fehler im USB Massenspeicher und Matrox Grafiktreiber behoben.
• Kleine Verbesserungen am Intel HD Audio Treiber.
• Der Code für TTY Handling wurde überprüft, dabei wurden Locking Issues gefunden, die bei Nutzung der seriellen Schnittstelle zu einem Kernel Panic führen können.
• Es wurde begonnen, den TTY Treiber für pseudo-TTY und Terminal und das TTY Modul für serielle Schnittstellen zusammenzuführen.
• TCP Optionen sind jetzt in der gleichen Reihenfolge wie bei anderen Betriebssystemen, was theoretisch egal sein sollte, aber einige TCP Implementationen erwarten keine andere Reihenfolge.
• Unterstützung für MSI-X Interrupts mit 64 Bit PCI BAR Adressen hinzugefügt.
• VESA und Framebuffer Grafik wurden in zwei verschiedene Treiber aufgeteilt, da sie nicht viel Code teilen und der VESA Treiber mehr Funktionen bekommt.
• Es wurde begonnen, die Netzwerktreiber mit FreeBSD 13 zu synchronisieren.
• Der Radeon HD Grafiktreiber wurde verbessert, um einige neuere Grafikkarten zu unterstützen.

Neben den allgemeinen Veränderungen und Verbesserungen findet auch immer mehr Arbeit an der Unterstützung für andere CPU Architekturen statt. Von dem RISC-V Port, über den wir bereits berichteten, wurden weitere Teile übernommen. Das beinhaltet Fehlerkorrekturen bei einigen Linker Scripts und einen Absturz, wenn Threads beendet werden.

Es wird ausserdem daran gearbeitet, den Kernel auf ARM64 zum Laufen zu bringen. Gleichzeitig wird sehr aktiv am ARM (32 Bit) Port gearbeitet. Hier startet der Kernel bereits, des Weiteren wurden folgende Verbesserungen erarbeitet: Der frühe Startprozess wurde aufgeräumt, Unterstützung für das ARM MMU und die Übergabe vom EFI Bootloader zum Kernel wurde hinzugefügt, Fehlerkorrekturen bei Linker Scripts, vollständigere Verarbeitung von ARM-spezifischen ELF Sektionen und einige weitere Dinge.

In einigen Fällen, zum Beispiel auf manchen ARM Geräten, gibt es keinen nativen Textmodus, weshalb der Bootloader jetzt so angepasst wird, dass er eine Text-Konsole (Textmodus auf einem VGA Bildschirm oder serielle Schnittstelle) oder einen Framebuffer mit direkter Pixelzeichnung unterstützt. Je nachdem, was von der Hardware unterstützt wird, wird der Bootloader zwischen Textmodus und Framebuffer entscheiden. Das kann auch bei Systemen mit sehr eingeschränktem Textmodus wie SPARC nützlich sein.

Auch am SPARC Port wurde gearbeitet. Hier gibt es erste Schritte bei der MMU Unterstützung. Bei SPARC wurde das MMU mehrmals bei verschiedenen CPU Generationen verändert und ist ein sehr simples Design, das viel Softwareunterstützung braucht. Als ersten Schritt muss der Kernel die Traps (Exceptions) vom MMU verarbeiten und ihm die korrekten Daten geben. Aber weil der Kernel im virtuellen Speicher arbeitet, muss das MMU funktionieren. Das ist alles möglich und im SPARC Architekturdesign geplant, aber braucht viel spezifischen Code für das erste Setup. Ein Teil dieses Codes muss direkt in Assembler geschrieben werden, was diesen Schritt nicht so einfach macht.

Zu guter Letzt möchte ich auch noch auf die allgemeinen Optimierungen am Code eingehen:

• Warnungen in video_producer_demo wurden behoben.
• Die Keymap Einstellungen und die Bildschirmtastatur teilen ihren Code für die Anzeige einer Tastatur auf dem Bildschirm wieder. Ursprünglich war der Code in der Bildschirmtastatur eine Kopie der Keymap Einstellungen, aber sie wurden unterschiedlich weiterentwickelt.
• Syslog, Power Daemon und mount_server nutzen die BServer Klasse, um sich mit dem app_server zu verbinden. Dadurch wird der Boot Prozess zuverlässiger und unnötige Abhängigkeiten zwischen den Services werden entfernt.
• Der Launch Daemon wurde überarbeitet, um ein Problem zu beheben, durch das der Desktop manchmal nicht startete.
• Es wird weiter am Beheben von Compiler Warnungen in allen Teilen des Codes gearbeitet, diesen Monat im Netzwerkstack, EFI Bootloader, netfs, Media Plugins, Translators, dem Kernel, Treibern und einigen anderen Stellen.
• Der Weg um schwache Symbole, Alias und versteckte Funktionen zu definieren, wurde an einem Platz zusammengefasst. Vorher wurden sehr ähnliche Makros an verschiedenen Stellen definiert und genutzt.
• Die Fehlermeldung von runtime_loader, wenn eine Bibliothek nicht gefunden wird, wurde verbessert. Sie zeigt jetzt an, welche andere Bibliothek versucht hat, sie zu laden. Das hilft beim Debuggen von ungewollten Abhängigkeiten.

Leider habe ich es aus privaten zeitlichen Gründen nicht geschafft, die letzten Activity Reports seit Mai zu übersetzen. Sie enthalten sehr interessante Informationen rund um die Weiterentwicklung des Projekts. Ich kann deshalb empfehlen, diese im englischen Original nachzulesen.

Quelle: https://www.haiku-os.org/blog/pulkomandy/2021-11-01-haiku_activity_report_october_2021/

Verwendet man WebDAV-Freigaben mit einer sicheren Verbindung unter Linux (gvfs) wird immer ein Zertifikatsfehler angezeigt, wenn man Let’s Encrypt als Zertifizierungsstelle verwendet. Durch manuellen Import der Zertifikate lässt sich das beheben.

Let’s Encrypt ist eine der größten Erfolge für die Sicherheit des Internets in den vergangenen Jahren. Im Gegensatz zu vielen anderen Vorhaben geschah diese auch endlich mal wieder durch die Gemeinschaft und nicht unter der Ägide eines der großen IT-Giganten. Mittels Let’s Encrypt sind verschlüsselte Verbindungen Standard geworden und die kommerziellen Zertifizerungsstellen wurden massiv zurückgedrängt.

WebDAV ist wiederum der Standard für Dateifreigaben im Internet, analog zu CalDAV für Kalendereinträge und CardDAV für Adressbücher. Viele proprietäre Dienste, aber auch solche wie das Open Source Flaggschiff Nextcloud setzen auf WebDAV.

Ausgerechnet diese beiden Dienste vertragen sich unter Linux nicht besonders gut. Versucht man bei einem Desktop, der auf GVFS basiert (GNOME Virtual File System) eine WebDAV-Freigabe mit HTTPS-Verbindung einzurichten, scheitert man mit einer kryptischen Fehlermeldung. Erschreckend vor allem, weil das Problem schon seit 2015 besteht, wie es Chris bei LinuxuUndIch damals beschrieb. Ich möchte das hier aufgreifen, weil einige Lösungsschritte von damals nicht mehr aktuell sind.

Das Problem ist relativ leicht erklärt. Zwar „vertrauen“ alle großen Browser den Let’s Encrypt-Stammzertifikaten, aber die Distributionen haben diese in ihre Systemzertifikate aus irgendwelchen Gründen immer noch nicht aufgenommen. Ob man davon betroffen ist, kann man auf der Konsole überprüfen, indem man dort die WebDAV-Freigabe einbindet. Wie immer sind die konkreten Angaben natürlich anzupassen.

$ gio mount davs://domain.de:0000/cloud

Erhält man dort eine Fehlermeldung mit einem ungültigen Zertifikat, ist man davon betroffen.

Die Lösung besteht darin, die Stammzertifikate manuell zu installieren. Diese kann man auf der Seite von Let’s Encrypt beziehen. Hier muss man verschiedene Zertifikate einspielen. Man benötigt die Root-Zertifikate und die Intermediate-Zertifikate, da bei mir z. B. alle Zertifikate mittelbar durch Let’s Encrypt R3 ausgestellt wurden.

$ wget https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.pem
$ wget https://letsencrypt.org/certs/lets-encrypt-x2-cross-signed.pem
$ wget https://letsencrypt.org/certs/lets-encrypt-r3.pem

Diese Zertifikate muss man anschließend mit Root-Rechten einspielen.

# trust anchor lets-encrypt-x1-cross-signed.pem
# trust anchor lets-encrypt-x2-cross-signed.pem
# trust anchor lets-encrypt-r3.pem

Abschließend kann man prüfen, ob alles ordnungsgemäß eingespielt wurden. Bei den Root Zertifikaten:

$ trust list | grep -C 2 "Let's Encrypt"
pkcs11:id=%A8%4A%6A%63%04%7D%DD%BA%E6%D1%39%B7%A6%45%65%EF%F3%A8%EC%A1;type=cert
    type: certificate
    label: Let's Encrypt Authority X1
    trust: anchor
    category: authority
--
pkcs11:id=%C5%B1%AB%4E%4C%B1%CD%64%30%93%7E%C1%84%99%05%AB%E6%03%E2%25;type=cert
    type: certificate
    label: Let's Encrypt Authority X2
    trust: anchor
    category: authority

Und beim Intermediate-Zertifikat:

$ trust list | grep -C 2 "R3"
pkcs11:id=%14%2E%B3%17%B7%58%56%CB%AE%50%09%40%E6%1F%AF%9D%8B%14%C2%C6;type=cert
    type: certificate
    label: R3
    trust: anchor
    category: authority

Bei Letzterem werden ggf. noch weitere Zertifikate gefunden. Hier muss man dann genau hinschauen.

Die abschließende Prüfung ist natürlich die WebDAV-Freigabe. Gibt es keine Fehlermeldung bei der Einbindung, ist alles glattgegangen.

Der Artikel Let’s Encrypt Zertifikatsfehler bei WebDAV beheben erschien zuerst auf [Mer]Curius

Di, 9. November 2021, Norbert Rüthers

Nach 2 Jahren ist nun wieder eine neue Hauptversion von Raspberry Pi OS herausgekommen.

Nachdem im August Debian Bullseye erschien, ist jetzt auch Raspberry Pi OS mit Raspberry Pi OS 2021-10-30 auf den neuesten Stand gebracht worden. Als Unterbau dient jetzt das neueste Debian.

Im Gegensatz zu Debian fielen die Änderungen bei Raspberry Pi OS aber eher moderat und im verborgenen aus. Am offensichtlichsten ist, das die Update-Funktion inzwischen nicht mehr rein über die Kommandozeile zu erreichen ist (apt update), sondern ein grafisches Plugin in der Taskleiste bekam.  Nun wird nach jedem booten bzw. alle 24 Stunden auf updates geprüft und diese ggf. angezeigt.

Ferner wurde GTK+ auf Version 3 gebracht. Eine der Änderungen, die mit disem Wechsel einherging, ist die Verwendung eines neuen Fenstermanagers namens mutter anstelle des in früheren Versionen verwendeten Openbox-Fenstermanagers. Ein Nachteil von mutter ist, dass es aufgrund der Notwendigkeit, den gesamten Bildschirm in den Speicher zu zeichnen, bevor es ihn anzeigen kann, ziemlich anspruchsvoll in Bezug auf den Arbeitsspeicher ist und nur auf einem Raspberry Pi mit 2 GB oder mehr richtig laufen kann. Daher wird auf Raspberry Pis mit weniger als 2 GB weiterhin der ältere Openbox-Fenstermanager verwendet

Die kompletten Release notes findet ihr hier

Di, 9. November 2021, Lioh Möller

Die vom Unternehmen CloudLinux ins Leben gerufene RHEL-kompatible Enterprise Distribution wird zusätzlich zu den klassischen Installationsmedien auch als Live-Variante zur Verfügung gestellt. Initiiert wurde dies von der Community im Rahmen einer SiG (Special Intrest Group).

Neben einer abgespeckten GNOME Version, werden ISOs mit Xfce, KDE Plasma sowie GNOME mit Zusatzsoftware wie LibreOffice und Thunderbird angeboten.

Die Live-Medien eignen sich gut, um einen Blick auf die Distribution zu werfen oder eine mögliche Hardwarekompatibilität zu testen.

Aktuell werden diese noch als Beta deklariert, was sich in naher Zukunft ändern soll. Mithilfe des integrierten Anaconda Installationsprogramms lässt sich die Distribution dauerhaft auf ein Speichermedium übertragen.

Download AlmaLinux 8 Live: https://repo.almalinux.org/almalinux/8/live/x86_64/

Mo, 8. November 2021, Ralf Hersel

Wie oft wird eine neue Kernelversion pro Jahr veröffentlicht? Wie lange wird ein Kernel unterstützt? Es gibt LTS-Kernel (Long Term Support). Wie lange werden die LTS-Linux-Kernel unterstützt? Die kurze Antwort ist, dass alle zwei bis drei Monate eine neue Kernelversion veröffentlicht wird. Die lange Antwort ist, dass es sich dabei nicht um eine feste Regel handelt.

Longterm release kernels

Das bedeutet, dass oft alle zwei bis drei Monate eine neue Kernelversion veröffentlicht wird. Das ist das Ziel des Kernel-Maintainer-Teams, aber es gibt keinen festen Termin, an dem die neue Version genau 8 Wochen nach der vorherigen Version veröffentlicht werden muss. Eine neue Kernel-Version wird (oft) von Linus Torvalds veröffentlicht, wenn sie fertig ist. Dies geschieht normalerweise alle 2 bis 3 Monate. Die Veröffentlichung wird als "stabil" deklariert und normalerweise im Format X.Y nummeriert.

Dies ist jedoch nicht das Ende der X.Y-Entwicklung. Die stabile Version erhält weitere kleinere Versionen, um Fehlerkorrekturen vorzunehmen. Diese kleinen Versionen fügen dem stabilen Kernel einen weiteren Punkt hinzu, um ihn wie X.Y.Z zu machen. Während X.Y (oft) vom Torvalds veröffentlicht wird, liegt die Verantwortung für die Pflege des stabilen X.Y-Kernels, die Einarbeitung von Fehlerkorrekturen und die Veröffentlichung von X.Y.Z-Versionen bei einem Kernel-Entwickler.

Wie bei der Veröffentlichung gibt es keine festen Termine und keinen Zeitplan dafür, wie lange eine Kernelversion unterstützt wird. Ein reguläres stabiles Kernel-Release wird in der Regel zweieinhalb bis drei Monate lang unterstützt, abhängig von der Veröffentlichung des nächsten stabilen Kernel-Release. Zum Beispiel würde der stabile Kernel 5.14 einige Wochen nach der Veröffentlichung des stabilen Kernels 5.15 das Ende seiner Lebensdauer erreichen. Das Ende der Unterstützung wird vom Betreuer der jeweiligen stabilen Kernelversion in der Linux-Kernel-Mailingliste bekannt gegeben. Benutzer und Mitwirkende werden gebeten, auf die neu veröffentlichte stabile Version umzusteigen.

Dies gilt nur für die normalen stabilen Kernel-Versionen. Es gibt auch LTS-Kernelversionen (Long Term Support), die für einen viel längeren Zeitraum als nur 3 Monate unterstützt werden. Auch für LTS-Kernel gibt es keinen festen Veröffentlichungszeitplan. Normalerweise gibt es jedes Jahr eine LTS-Kernel-Veröffentlichung, meist die letzte des Jahres, und sie wird mindestens zwei Jahre lang unterstützt. Aber auch hier gibt es keine festen Regeln.

Der Betreuer eines LTS-Kernels kann zustimmen, einen bestimmten LTS-Kernel länger, als die üblichen zwei Jahre zu betreuen. Die Vereinbarung wird auf der Grundlage der Notwendigkeit und der beteiligten Akteure getroffen. Dies geschieht häufig bei Android-Projekten. Da zwei Jahre für die Hersteller nicht ausreichen, um ihre Hardware- und Softwarefunktionen zu unterstützen, werden einige LTS-Kernel oft sechs Jahre lang unterstützt.

Wenn man die Version des eigenen Linux-Kernels überprüft, stellt man möglicherweise fest, dass die Distribution einen alten Kernel verwendet. Es könnte auch sein, dass der von der Distribution angebotene Kernel laut Kernel-Website das Ende seiner Lebensdauer erreicht hat. Kein Grund zur Panik. Die Distribution kümmert sich darum, den Kernel mit Patches für Fehlerbehebungen und Sicherheitslücken zu versorgen. Wer nicht gerade eine obskure Linux-Distribution verwendet, kann sich darauf verlassen, dass die Distribution den Kern sicher und stabil hält.

Selbstverständlich ist es möglich den neuesten Linux-Kernel in Ubuntu oder einer anderen Distribution zu installieren, wenn man gute Gründe dafür hat, wie z. B. die Unterstützung für neuere Hardware.

Quelle: https://www.kernel.org/category/releases.html

In diesem Artikel gebe ich euch einen Überblick, was Network Bound Disk Encryption (NBDE) ist und beschreibe einen konkreten Anwendungsfall. Am Ende des Artikels führe ich einige Verweise auf, mit deren Hilfe ihr NBDE bei Interesse selbst implementieren könnt.

Linux Unified Key Setup (LUKS)

Bevor ich auf NBDE eingehe, möchte ich kurz ein paar Worte zu LUKS verlieren.

Bei LUKS handelt es sich um das Standardverfahren zur Festplattenverschlüsselung unter Linux (siehe 1). Dieses erweitert dm-crypt um einen Header, welcher Slots zum Speichern von bis zu acht Schlüsseln bietet (siehe 2).

Ich benutze dieses Verfahren auf nahezu all meinen Rechnern. Ich möchte damit erreichen, dass meine Daten bei Diebstahl des Rechners bzw. der Festplatte möglichst lange vor unberechtigtem Zugriff geschützt sind.

Typischerweise wird zur Entschlüsselung einer Festplatte bzw. Partition während des Boot-Vorgangs die Eingabe eines Kennworts benötigt. Die Sicherheit des Verfahrens hängt dabei direkt von der Stärke des verwendeten Passworts ab (siehe 1).

Steht der Rechner im Büro und man ist täglich vor Ort, ist es kein Problem, bei Neustart des Rechners das LUKS-Kennwort einzugeben. Wenn man allerdings im Homeoffice arbeitet und Zugriff auf seinen Büro-Rechner braucht, sieht die Sache anders aus.

Möchte man den entfernten Rechner neustarten, z.B. nach der Installation von Updates, muss man dafür extra ins Büro fahren. Alternativ kann man ein zweites Kennwort einrichten, dieses einem Kollegen mitteilen und diesen bitten, es vor Ort einzugeben. Beides ist nicht komfortabel. Und hier kommt NBDE ins Spiel.

LUKS an Netzwerkressource binden

Network Bound Disk Encryption heißt auf Deutsch in etwa netzwerkgebundene Festplattenverschlüsselung und bedeutet, dass die Verschlüsselung an eine oder mehrere Ressourcen im Netzwerk gebunden ist.

Das Prinzip ist ganz einfach. Wenn ein Rechner mit einer verschlüsselten Festplatte oder Partition startet, sucht er nach einer bestimmten Ressource im Netzwerk. Kann der Rechner diese Netzwerkressource erreichen, wird die Festplatte bzw. Partition entschlüsselt und der Startvorgang fortgesetzt. Folgende Abbildung soll dies veranschaulichen.

Im eigenen LAN werden zwei sogenannte Tang-Server positioniert (siehe 4 und 6). Diese stellen die Netzwerk-Ressource dar, welche erreichbar sein muss, damit ein an Tang gebundenes Gerät entschlüsselt werden kann. In diesem Beispiel werden zwei Tang-Server betrieben, um die Verfügbarkeit des Dienstes zu gewährleisten, wenn ein Server gewartet wird.

Auf dem Client kommt die Anwendung Clevis zum Einsatz (siehe 5, 6 und 7), bei welcher es sich um die Client-Komponente zum Tang-Server handelt. Diese empfängt einen Schlüssel vom Tang-Server und verwendet diesen, um einen Token in einem LUKS-Slot zu speichern (Details siehe 3, 6 und 7). Beim Start eines Rechners wird nun versucht, einen der Tang-Server zu erreichen, an die man sich gebunden hat.

Wird der Rechner bzw. seine Festplatte gestohlen, sind die Tang-Server nicht erreichbar und die Daten werden nicht automatisch entschlüsselt. Der Dieb muss nun die Verschlüsselung bzw. das verwendete Kennwort brechen.

Steht der Rechner jedoch an seinem Platz, kann er aus der Ferne neugestartet werden und den Startvorgang beenden, ohne dass jemand vor Ort ein LUKS-Kennwort eingeben muss.

Damit diese Konfiguration Sinn macht, dürfen die Tang-Server nicht weltweit erreichbar sein. Ihr Standort und die Netze, aus denen sie erreichbar sind, sind daher sorgfältig zu planen.

Zusammenfassung

Ohne NBDE muss an einem Rechner mit LUKS-Verschlüsselung bei jedem Startvorgang das LUKS-Kennwort eingegeben werden, was einen Neustart aus der Ferne enorm erschwert.

NBDE ist leicht zu implementieren und löst dieses Problem. Gleichzeitig bleiben die Daten im gleichen Maße bei einem Diebstahl des Rechners geschützt.

Quellen und weiterführende Links

1. LUKS im Wiki von Ubuntuusers.de. URL: https://wiki.ubuntuusers.de/LUKS/
2. https://de.wikipedia.org/wiki/Dm-crypt#LUKS
3. Automatic data encryption and decryption with Clevis and Tang. ADMIN 43/2018. URL: https://www.admin-magazine.com/Archive/2018/43/Automatic-data-encryption-and-decryption-with-Clevis-and-Tang
4. https://github.com/latchset/tang
5. https://github.com/latchset/clevis
6. RHEL 8 Security Hardening Chapter 12. Configuring automated unlocking of encrypted volumes using policy-based decryption. URL: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-automated-unlocking-of-encrypted-volumes-using-policy-based-decryption_security-hardening
7. RHEL 7 Security Guide 4.10.1. Network-Bound Disk Encryption. URL: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-policy-based_decryption#sec-Using_Network-Bound_Disk_Encryption
8. How to set up Network-Bound Disk Encryption with multiple LUKS devices (Clevis+Tang unlocking). URL: https://access.redhat.com/articles/4500491. (Login erforderlich)