Mo, 6. Dezember 2021, Ralf Hersel

EndeavourOS ist eine rollende Linux-Distribution, die auf Arch Linux basiert. Das Projekt bietet eine einfach einzurichtende und vorkonfigurierte Desktop-Umgebung auf der Basis von Arch. Bei EndeavourOS gibt es sowohl Offline- als auch Online-Installationsoptionen. Der Offline-Installer, Calamares, verwendet standardmässig den Xfce-Desktop. Das Online-Installationsprogramm kann optionale Softwarekomponenten installieren, darunter die meisten gängigen Desktop-Umgebungen.

Was ist neu in EndeavourOS Atlantis? Version 21.4 verwendet den Linux Kernel 5.15 (LTS). Atlantis bleibt bei Xfce 4.16 als Standard-Desktop-Umgebung bei der Live-Sitzung und fügt einige Verbesserungen und neue Ergänzungen zu den EndeavourOS-Anwendungen/Tools hinzu. So gibt es beispielsweise eine neue Sicherheitsüberprüfung für Benutzer von NVIDIA-GPUs und Kernel-Updates, um Boot-Fehler nach einem Update zu verhindern.

Zu den weiteren Neuerungen gehören:

• Das Werkzeug eos-apps-info ist nun standardmässig installiert
• Die Welcome-App hat eine neue Schaltfläche erhalten, die den Benutzer zu einer Seite mit weiteren Informationen über die vorinstallierte Desktop-Umgebung führt
• Das Tool eos-apps-info-helper wurde aktualisiert, um Informationen über weitere Apps anzuzeigen
• eos-update-notifier hat ein neues und verbessertes Zeitplan-Konfigurationsfenster erhalten
• paccache-service-manager ermöglicht es dem Benutzer nun, den Cache von deinstallierten Paketen zu löschen.

Ebenfalls verbessert wurde das grafische Installationsprogramm Calamares, das die Installation von Arch Linux für Neueinsteiger erleichtert. Der Installer unterstützt jetzt die gleichzeitige Installation der Xfce-Desktop-Umgebung und des i3-Fenstermanagers, fügt zstd für Btrfs für die Installation auf SSD- und HDD-Laufwerken hinzu, aktiviert standardmässig fstrim.timer, verwendet zufällige EFI-Pfadbenennungen, unterstützt das Lesen der Ausgabe von pacman-Aktionen, aktiviert standardmässig DRM-Modi für NVIDIA-GPU-Benutzer und ermöglicht es Benutzern, Installationsprotokolle an die Entwickler zu senden.

Auswahl der Desktop-Umgebungen während der Installation

Weitere interessante Änderungen im Calamares-Installationsprogramm sind die Unterstützung für EndeavourOS-Repos und die Welcome-App, die standardmässig eine Verbindung zu GitLab herstellt, die Entfernung von GitHub aus der EndeavourOS-Spiegelliste und eine neue Methode für die Installation einer der EndeavourOS Community-Editionen.

"Jetzt wählt man zuerst die Community-Edition aus, die ein festes Einstellungspaket ist, das nicht verändert werden kann, um fehlgeschlagene Installationen zu vermeiden, und gelangt dann zum Basispaketmodul, wo man bestimmte Pakete abwählen kann, wenn man das möchte", heisst es in der Ankündigung.

Neben anderen Änderungen verbessert EndeavourOS Atlantis Legacy Boot, führt die Möglichkeit für Benutzer ein, ihre eigenen Bash-Befehle zu schreiben, wird mit installiertem OS Prober ausgeliefert. Atlantis wird mit installiertem PipeWire für Audio ausgeliefert, verbessert die Unterstützung für bestimmte PCIe-basierte M.2-Laufwerke, ersetzt den Treiber r8168 durch r8169 und fügt mehrere neue Hintergrundbilder hinzu.

EndeavourOS Atlantis kann von der Webseite des Projekts herunterladen und installiert werden. Weitere Details zur neuen Version finden sich in den Release Notes:

Quelle: https://endeavouros.com/news/the-atlantis-release-is-in-orbit/

Dieser Blogpost enthält meine Antwort auf den Meinungsartikel von Niklas auf GNU/Linux.ch: „Verliert die Free-Software-Community ihre Werte?“

Niklas weist in seinem Artikel auf den Umstand hin, dass zur Bereitstellung von, Verteilung von, Beteiligung an und Diskussion um Freie-Software-Projekte vermehrt Werkzeuge genutzt werden, welche einer proprietären Lizenz unterliegen. Er kritisiert, dass dies die Freiheit Nr. 3 einschränkt:

Freiheit 3: Die Freiheit, das Programm zu verbessern und diese Verbesserungen der Öffentlichkeit freizugeben, damit die gesamte Gemeinschaft davon profitiert.

https://gnulinux.ch/verliert-die-free-software-community-ihre-werte

Aus Niklas‘ Sicht werden durch die Verwendung proprietärer Werkzeuge/Plattformen wie z.B. GitHub und Discord Nutzer davon abgehalten bzw. daran gehindert, sich an der Entwicklung freier Software zu beteiligen. Niklas schließt seinen Artikel mit folgenden Fragen, die ich in diesem Beitrag gern beantworten möchte.

… Habt ihr selbst Projekte? Werdet ihr etwas verändern? Beteiligt ihr euch an Projekten? Werdet ihr eure Bedenken weitergeben? War der Artikel hilfreich?…

https://gnulinux.ch/verliert-die-free-software-community-ihre-werte

Ja, ich habe einige Projekte. Einige habe ich auf GitHub veröffentlicht. Andere werden in der GitLab-Instanz der Universität Bielefeld gepflegt. Damit verwende auch ich ein proprietäres Werkzeug für meine eigenen Projekte.

Darüber hinaus nutze ich GitHub auch, um mich an diversen anderen Projekten zu beteiligen. Und es gefällt mir, weil es mir die (Mit-)Arbeit und Beteiligung so einfach macht. Hier sind viele Projekte, die mich interessieren. Hier suchen viele Nutzer nach interessanten Projekten. Mit dieser Plattform erreiche ich mit meinen Projekten viele potenzielle Nutzer. Ich finde es praktisch, den Issue-Tracker und die Verwaltung der Pull Requests dabei zu haben. Und nicht zuletzt ist das Hosting meiner Projekte hier kostenfrei.

Dass es sich bei GitHub nicht um Freie Software handelt, hat mich bisher nicht gestört. Ich habe allerdings auch noch nicht bewusst darüber nachgedacht.

Da ich IRC nicht mag, es mich eher stört, wenn jedes Projekt sein eigenes Forum betreibt, für das ich mich erst registrieren muss, finde ich es praktisch, dass ich mich mit einem GitHub-Account an so vielen Projekten beteiligen und mich über den Issue-Tracker mit ihnen austauschen kann. Daneben schätze ich noch, wenn die Möglichkeit besteht, mit einem Projekt via E-Mail in Kontakt zu treten, da dies für mich persönlich die geringste Hürde darstellt.

Allerdings kann ich Niklas auch gut folgen. Vermutlich würde ich mich nicht bei Discord registrieren, um mich an einem Projekt beteiligen zu können. Dass ich mit einigen Projekten ausschließlich über Google-Groups kommunizieren kann, finde ich ebenfalls doof, ist hierfür doch ein Google-Konto Voraussetzung.

Ich besitze auch noch einige Zugänge zum Bugzilla von Red Hat (https://bugzilla.redhat.com) und bin dort hin und wieder aktiv. Bugzilla steht unter einer Open-Source-Lizenz. Der Bugtracker wird in diesem Fall von einem profitorientierten Unternehmen betrieben (Red Hat). Macht es das schon besser als GitHub, eine proprietäre Anwendung in den Händen eines profitorientierten Unternehmens (Microsoft)? Ich weiß es nicht.

In beiden Fällen (Red Hat Bugzilla und GitHub) finde ich persönlich meine Freiheit Nr. 3 nicht beschränkt. Im Gegenteil. Empfinde ich es doch als Erleichterung, mich an Projekten beteiligen zu können.

Niklas hat in seinem Artikel Codeberg erwähnt, welches ich bisher noch nicht kannte. Es handelt sich dabei um eine Kollaborationsplattform Git-Hosting für Freie- und Open-Source-Software. Auf den ersten Blick bietet das Projekt Codeverwaltung, Issue-Tracker und Pull-Request-Verwaltung. Alles unter einer freien Lizenz. Betrieben wird die Plattform vom gemeinnützigen Verein Codeberg e.V., dessen Satzung hier eingesehen werden kann. Die Idee und Motivation des Vereins gefällt mir und ich halte diese für unterstützenswert.

Codeberg bietet scheinbar die Funktionalität, welche ich für meine Projekte benötige. Werde ich jetzt etwas verändern? Nun, ich kann mir gut vorstellen, mein nächstes Projekt auf Codeberg zu hosten. Erst wenn ich die Plattform einige Zeit selbst genutzt habe, kann ich mir ein Urteil darüber bilden.

An Niklas gerichtet: Ja, ich finde deinen Artikel hilfreich. Er regt zum Nachdenken an und ich habe dadurch eine Plattform kennengelernt, die ich bisher noch nicht kannte und welche auf den ersten Blick einen guten Eindruck macht.

Nun habe ich noch eine Frage an meine Leser hier. Wenn ein Projekt seinen Code nicht auf GitHub hostet, stellt dies für euch eine Hürde dar, die Software zu verwenden oder euch am Projekt zu beteiligen? Oder senkt dies eure Hemmschwelle sogar?

Open Source macht ein System noch nicht sicher. Dazu gehört heute viel mehr. Die Maßnahmenkette reicht von Updates bis hin zum sogenannten verifizierten Boot. Ein kleiner Überblick über den Unterschied von GrapheneOS zu anderen Projekten.

XDA Developers ist voll von tollen quelloffenen Projekten, die trotzdem Geräte produzieren, die so unsicher sind, dass man vermutlich mit einem China-Smartphone samt Herstellersoftware sicherer unterwegs ist.

Drei Faktoren heben hier GrapheneOS von anderen AftermarketOS („Custom ROMs“) ab.

1. Updates für Firmware und Kernel
2. Verified Boot
3. Notwendige Hardware-Eigenschaften
4. Open Source & Hardening

GrapheneOS – Maßnahmen für mehr Sicherheit

1. Updates für Firmware und Kernel

Android in der AOSP-Variante (Android Open Source Project) steht unter einer freien Lizenz und kann von jedem verwendet und adaptiert werden. Das gilt aber nur für das Betriebssystem und nicht für den Linux-Kernel und die Firmware. Diese Bestandteile variieren von Gerät zu Gerät. So nutzt mein Google Pixel 6 z. B. den Linux-Kernel in Version 5.10, während mein Samsung Galaxy S10 den Linux-Kernel in Version 4.14 verwendet. Beides wird sich voraussichtlich über die gesamte Nutzungszeit nicht ändern.

Der Grund dafür ist die Treiberversorgung. Im Gegensatz zu Linux auf dem Desktop ist ein Großteil der Treiber nicht im sogenannten Mainline-Kernel und deshalb kann der Kernel nicht beliebig aktualisiert werden. Das stellt auch die Hersteller vor Probleme, wie immer wieder gebrochene Updateversprechen zeigen. So lange das Gerät noch herstellerseitig unterstützt wird, ist das nur ein beschränktes Problem. Die Entwickler alternativer Betriebssysteme können dann die Updates des Herstellers für die freie Variante übernehmen. In dem Moment, in dem der Hersteller den Support einstellt, gibt es keine Updates für den Kernel mehr. Mithin die wichtigste Komponente des Systems. Auf diesen dann zusehend marode werdenden Kern kann man noch einige Zeit neue AOSP-Versionen aufsetzen, aber die Sicherheitslücken nehmen naturgemäß zu.

Deutlich problematischer ist hier die Versorgung mit der sogenannten Firmware. In der Szene gern mit Baseband, Radio, Modem etc. umschrieben. Auch hier gibt es Sicherheitsaktualisierungen, aber diese können in der Regel nicht über Updates von z. B. LineageOS eingespielt werden. Bei Samsung muss der Besitzer dies – so er nicht das Samsung Stock Android nutzt – über Software wie Odin oder Heimdall im Downloadmodus erledigen. Die Wahrscheinlichkeit, sein Gerät damit unbrauchbar (soft bricked oder noch schlimmer hard bricked) ist gar nicht so unwahrscheinlich. Entsprechend machen das die meisten Nutzer von AftermarketOS-Systemen nicht oder zumindest nicht regelmäßig.

Für das notorische Problem der kurzen Hardwareunterstützung im Android-Ökosystem bietet somit auch GrapheneOS keinen Ausweg. Deshalb unterstützt man nur wenige Geräte (die Google Pixel-Serie) und diese auch nur so lange, wie Google upstream noch Support für die Geräte bietet. Die von Google angekündigten 5 Jahre für das Google Pixel 6 lassen hier aber hoffen, da GrapheneOS dies hoffentlich übernehmen wird.

2. Verified Boot

Die Wahl auf die Pixel-Geräte von Google fiel sicher nicht, weil Google allseitig so beliebt ist, sondern weil die Pixel-Geräte offiziell die Installation anderer Betriebssysteme erlauben.

Dazu muss man sich vergegenwärtigen wie bei anderen Geräten AftermarketOS aufgespielt werden: Immer muss der Bootloader mit komplizierten Methoden über Klammergriffe oder Herstellercodes, manchmal sogar über Maßnahmen an der Grenze zum „Hacking“ (also über z. B. das Ausnutzen von Fehlern) geöffnet werden. Dieser lässt sich anschließend auch nicht mehr schließen. Dadurch lässt sich nicht nur jederzeit ein anderer Betriebssystem installieren, die „Verified Boot„-Kette lässt sich auch nicht mehr gewährleisten. Durch diesen wird sichergestellt, dass das ausgeführte System aus einer vertrauenswürdigen Quelle stammt und nicht manipuliert wurde. Der Rollback-Schutz verhindert zudem, dass ein Exploit sich dauerhaft im System einnistet.

Geräte ohne „Verified Boot“ sind per Definition einfach nicht sicher. Der Datenschutz hinsichtlich Datenabfluss im Betrieb mag vielleicht besser als bei einem Stock Android sein (was aber auch wieder von Konfiguration und genutzten Apps abhängt), aber die Sicherheit ist massiv viel schlechter. Vor allem wenn man an Szenarien denkt, bei denen Angreifer physischen Zugang zum Gerät haben.

Bei GrapheneOS kann und sollte der Bootloader nach der Installation wieder geschlossen werden. Die vollständige Vertrauenskette beim Start ist anschließend wieder intakt.

3. Notwendige Hardware-Eigenschaften

Aktuelle Versionen von Android, Kernel, Firmware und eine verifizierte Vertrauenskette beim Start sind wichtige Aspekte. Zusätzlich kommen weitere Faktoren hinzu. Auf modernen Smartphones werden immer sensiblere Informationen gespeichert. Ganz besonders brisant sind biometrische Daten für Fingerabdruck oder Gesichtserkennung.

Apple hat hier vor einigen Jahren mit dem Secure Enclave Maßstäbe gesetzt, indem man begonnen hat, solche Daten auch hardwareseitig separiert auf dem Gerät zu speichern. Google nennt seine Lösung Titan Sicherheitschip. Beim Pixel 6 kommt der weiterentwickelte Titan M2 zum Einsatz. (Dieser basiert übrigens auf RISC-V wie die Szene interessiert zur Kenntnis nahm)

Der Titan M2 dient unter anderem dazu, dort biometrische Daten zu speichern. Zusätzlich können Apps via Android-API dort private Schlüssel hinterlegen. Der Titan M2 soll eine Extraktion dieser Daten erfolgreich verhindern.

Wegen fehlender entsprechender Sicherheitsmaßnahmen hatte ich z. B. von der Verwendung von Fingerabdrucksystemen bei herkömmlichen Linux-Systemen abgeraten.

4. Open Source & Hardening

Last, but not least: GrapheneOS ist Open Source. Die Entwickler bauen direkt auf AOSP auf und übernehmen Android damit nicht mittelbar über ein drittes Projekt, wie dies in der Szene oft der Fall ist. Es gibt zudem keine proprietären Bestandteile und keine Google-Dienste in der Standardinstallation.

Hinzu kommen zahlreiche Eigenentwicklungen wie der Chromium-Fork Vanadium als Browser, ein eigener PDF-Viewer, eine eigene Kamera-App und zahlreiche Modifikationen für die Sicherheit („Hardening“). Momentan experimentiert man mit sogenannten „Sandboxed Play Services“, was ein interessanter Ansatz für jene sein könnte, die partout nicht auf Google-Dienste verzichten können.

Wer von einem LineageOS-System umsteigt, wird den Unterschied sofort sehen.

Alternativen

Die möglichen Alternativen zu GrapheneOS sind sehr überschaubar. Eine Möglichkeit ist CalxyOS, das eine ähnliche Zielsetzung wie GrapheneOS verfolgt. (Einen ausführlichen Test von CalxyOS kann man bei Golem lesen) Das erkennt man nicht zuletzt an der nahezu identischen Geräteauswahl beider Systeme. Es gibt halt nicht viel Android-Hardware, das diese Vorgaben erfüllt. Die meisten der oben genannten Punkte treffen deshalb auch auf CalyxOS zu.

CalyxOS versucht es dem Anwender ein bisschen leichter zu machen und integriert daher ein paar mehr Funktionen als GrapheneOS in den Standardumfang bzw. erlaubt es dem Anwender diese leicht einzurichten. CalyxOS könnte daher vor allem jene interessieren, die ein paar mehr Kompromisse eingehen müssen. CalyxOS könnte zudem interessant sein, wenn man ein sicheres Android für Familienmitglieder sucht.

Aus meiner persönlichen Sicht sind einige der Funktionen fraglich und werfen einen Schatten auf das Projekt. Dazu gehört nicht nur microG (weil man damit eben doch Google ins System holt), sondern auch die Bewerbung von VPN (weil VPN nichts mit Anonymität zu tun hat), der massenhaften Leitung von Daten über Tor oder Cloudflare-DNS. Das ist aber klagen auf extrem hohen Niveau!

Außer GrapheneOS oder CalyxOS gibt es allerdings nicht viel. Herkömmliche Linux-Systeme, auch solche von Purism, haben viele der Sicherheitsfunktionen, die in den letzten Jahren Standard im Mobilbereich geworden sind, nicht implementiert. Das gilt ebenso für halbfreie Systeme wie Sailfish OS. Sie können also bestenfalls in einer Liga mit LineageOS spielen. Weitere Informationen dazu im ersten Teil der Serie.

Zwei große Defizite

Das erste Defizit liegt in der Geräteauswahl. So gut sie auch begründet ist und so wenig Alternativen es auch gibt, der Ansatz Google Geld für ein Gerät zu überweisen, um anschließend Google mittels eines anderen Systems zu entkommen, verdeutlicht die ganze Schizophrenie der technischen Gegenwart. Für viele – auch für mich – war und ist dies ein großes Hindernis, aber vielleicht der Preis, den man momentan bezahlen muss.

GrapheneOS ist letztlich von der Entwicklung bei Google (Hardware-Support durch Upstream) und AOSP abhängig. Ohne Android gäbe es auch kein GrapheneOS. Ob die AOSP-Community stark genug wäre, das System zu pflegen oder weiterzuentwickeln, wenn Google eines Tages beispielsweise zu Fuchsia wechseln sollte, steht in den Sternen. Es ist somit eine Freiheit von Googles Gnaden.

Der Artikel GrapheneOS – Viele Maßnahmen für die Sicherheit erschien zuerst auf [Mer]Curius

Ich spiele zur Zeit mit XWiki als Ersatz für mein privates DokuWiki herum. Die Installation ist unter Debian mithilfe eigenem Repo schnell erledigt. In meinem Fall habe ich mich für das xwiki-tomcat9-mariadb Paket entschieden, dass nicht nur XWiki sondern, wie auch der Name schon vermuten lässt Tomcat 9 und die Anbindung an MariaDB mitbringt.

Nach einem ersten Upgrade ist mir nun allerdings aufgefallen, dass ich keinerlei Seiten mehr bearbeiten konnte, da laut Fehlermeldung kein "Lock" der Seite stattfinden konnte. Nach kurzer Recherche stellte sich heraus, dass Tomcat nicht weiß, dass nginx per SSL läuft. Daher kurz und knapp alle Punkte, die nötig sind, damit XWiki mit nginx und SSL genutzt werden kann. Dies ist meiner Meinung nach in der offiziellen Doku leider etwas unübersichtlich.

In der Datei /etc/tomcat9/server.xml nach folgender Zeile suchen:

<Engine name="Catalina" defaultHost="localhost">

Und dort drunter folgenden Part ergänzen:

    <Valve className="org.apache.catalina.valves.RemoteIpValve"
      internalProxies="127\.0\.[0-1]\.1"
      remoteIpHeader="x-forwarded-for"
      requestAttributesEnabled="true"
      protocolHeader="x-forwarded-proto"
      protocolHeaderHttpsValue="https">
    </Valve>

Weiter geht es in der /etc/xwiki/xwiki.cfg, dort folgende Zeile einkommentieren:

xwiki.url.protocol=https

Ich möchte schöne, kurze URLs haben. Standardmäßig hängt XWiki hinter die URL noch ein /xwiki. Dies lässt sich wie folgt entfernen:

Die XWiki Config vom Tomcat umbennen:

mv /etc/tomcat9/Catalina/localhost/xwiki.xml /etc/tomcat9/Catalina/localhost/ROOT.xml

In /etc/xwiki/xwiki-tomcat9.xml suchen nach:

<Context path="/xwiki" docBase="/usr/lib/xwiki"
         containerSciFilter="org.apache.tomcat.websocket.server.WsSci|org.apache.jasper.servlet.JasperInitializer">

und bei Context path /xwiki durch / ersetzen.

Abschließend noch meine nginx-Config:

server {
    listen [::]:443 ssl http2;
    listen 443 ssl http2;
    server_name wiki.deineDomain.de;

    root /var/www/html;

    # Configuration to avoid Request Entity too large error 413
    client_max_body_size 0;
    ssl_certificate /etc/letsencrypt/deineDomain/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/deineDomain/key.pem;

    access_log /var/log/nginx/wiki.deineDomain.access_ssl.log;
    error_log /var/log/nginx/wiki.deineDomain.error_ssl.log;

    location / {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Scheme $scheme;
        proxy_redirect off;
        if (!-f $request_filename) {
            proxy_pass http://127.0.0.1:8080;
            break;
        }
    }

    location ~ /.well-known {
        allow all;
    }
 }

Dienste neustarten

systemctl restart tomcat9.service
systemctl restart nginx

Fertig.

Ich spiele zur Zeit mit XWiki als Ersatz für mein privates DokuWiki herum. Die Installation ist unter Debian mithilfe eigenem Repo schnell erledigt. In meinem Fall habe ich mich für das xwiki-tomcat9-mariadb Paket entschieden, dass nicht nur XWiki sondern, wie auch der Name schon vermuten lässt Tomcat 9 und die Anbindung an MariaDB mitbringt.

Nach einem ersten Upgrade ist mir nun allerdings aufgefallen, dass ich keinerlei Seiten mehr bearbeiten konnte, da laut Fehlermeldung kein "Lock" der Seite stattfinden konnte. Nach kurzer Recherche stellte sich heraus, dass Tomcat nicht weiß, dass nginx per SSL läuft. Daher kurz und knapp alle Punkte, die nötig sind, damit XWiki mit nginx und SSL genutzt werden kann. Dies ist meiner Meinung nach in der offiziellen Doku leider etwas unübersichtlich.

In der Datei /etc/tomcat9/server.xml nach folgender Zeile suchen:

<Engine name="Catalina" defaultHost="localhost">

Und dort drunter folgenden Part ergänzen:

    <Valve className="org.apache.catalina.valves.RemoteIpValve"
      internalProxies="127\.0\.[0-1]\.1"
      remoteIpHeader="x-forwarded-for"
      requestAttributesEnabled="true"
      protocolHeader="x-forwarded-proto"
      protocolHeaderHttpsValue="https">
    </Valve>

Weiter geht es in der /etc/xwiki/xwiki.cfg, dort folgende Zeile einkommentieren:

xwiki.url.protocol=https

Ich möchte schöne, kurze URLs haben. Standardmäßig hängt XWiki hinter die URL noch ein /xwiki. Dies lässt sich wie folgt entfernen:

Die XWiki Config vom Tomcat umbennen:

mv /etc/tomcat9/Catalina/localhost/xwiki.xml /etc/tomcat9/Catalina/localhost/ROOT.xml

In /etc/xwiki/xwiki-tomcat9.xml suchen nach:

<Context path="/xwiki" docBase="/usr/lib/xwiki"
         containerSciFilter="org.apache.tomcat.websocket.server.WsSci|org.apache.jasper.servlet.JasperInitializer">

und bei Context path /xwiki durch / ersetzen.

Abschließend noch meine nginx-Config:

server {
    listen [::]:443 ssl http2;
    listen 443 ssl http2;
    server_name wiki.deineDomain.de;

    root /var/www/html;

    # Configuration to avoid Request Entity too large error 413
    client_max_body_size 0;
    ssl_certificate /etc/letsencrypt/deineDomain/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/deineDomain/key.pem;

    access_log /var/log/nginx/wiki.deineDomain.access_ssl.log;
    error_log /var/log/nginx/wiki.deineDomain.error_ssl.log;

    location / {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Scheme $scheme;
        proxy_redirect off;
        if (!-f $request_filename) {
            proxy_pass http://127.0.0.1:8080;
            break;
        }
    }

    location ~ /.well-known {
        allow all;
    }
 }

Dienste neustarten

systemctl restart tomcat9.service
systemctl restart nginx

Fertig.

Ich spiele zur Zeit mit XWiki als Ersatz für mein privates DokuWiki herum. Die Installation ist unter Debian mithilfe eigenem Repo schnell erledigt. In meinem Fall habe ich mich für das xwiki-tomcat9-mariadb Paket entschieden, dass nicht nur XWiki sondern, wie auch der Name schon vermuten lässt Tomcat 9 und die Anbindung an MariaDB mitbringt.

Nach einem ersten Upgrade ist mir nun allerdings aufgefallen, dass ich keinerlei Seiten mehr bearbeiten konnte, da laut Fehlermeldung kein "Lock" der Seite stattfinden konnte. Nach kurzer Recherche stellte sich heraus, dass Tomcat nicht weiß, dass nginx per SSL läuft. Daher kurz und knapp alle Punkte, die nötig sind, damit XWiki mit nginx und SSL genutzt werden kann. Dies ist meiner Meinung nach in der offiziellen Doku leider etwas unübersichtlich.

In der Datei /etc/tomcat9/server.xml nach folgender Zeile suchen:

<Engine name="Catalina" defaultHost="localhost">

Und dort drunter folgenden Part ergänzen:

    <Valve className="org.apache.catalina.valves.RemoteIpValve"
      internalProxies="127\.0\.[0-1]\.1"
      remoteIpHeader="x-forwarded-for"
      requestAttributesEnabled="true"
      protocolHeader="x-forwarded-proto"
      protocolHeaderHttpsValue="https">
    </Valve>

Weiter geht es in der /etc/xwiki/xwiki.cfg, dort folgende Zeile einkommentieren:

xwiki.url.protocol=https

Ich möchte schöne, kurze URLs haben. Standardmäßig hängt XWiki hinter die URL noch ein /xwiki. Dies lässt sich wie folgt entfernen:

Die XWiki Config vom Tomcat umbennen:

mv /etc/tomcat9/Catalina/localhost/xwiki.xml /etc/tomcat9/Catalina/localhost/ROOT.xml

In /etc/xwiki/xwiki-tomcat9.xml suchen nach:

<Context path="/xwiki" docBase="/usr/lib/xwiki"
         containerSciFilter="org.apache.tomcat.websocket.server.WsSci|org.apache.jasper.servlet.JasperInitializer">

und bei Context path /xwiki durch / ersetzen.

Abschließend noch meine nginx-Config:

server {
    listen [::]:443 ssl http2;
    listen 443 ssl http2;
    server_name wiki.deineDomain.de;

    root /var/www/html;

    # Configuration to avoid Request Entity too large error 413
    client_max_body_size 0;
    ssl_certificate /etc/letsencrypt/deineDomain/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/deineDomain/key.pem;

    access_log /var/log/nginx/wiki.deineDomain.access_ssl.log;
    error_log /var/log/nginx/wiki.deineDomain.error_ssl.log;

    location / {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Scheme $scheme;
        proxy_redirect off;
        if (!-f $request_filename) {
            proxy_pass http://127.0.0.1:8080;
            break;
        }
    }

    location ~ /.well-known {
        allow all;
    }
 }

Dienste neustarten

systemctl restart tomcat9.service
systemctl restart nginx

Fertig.

Ich spiele zur Zeit mit XWiki als Ersatz für mein privates DokuWiki herum. Die Installation ist unter Debian mithilfe eigenem Repo schnell erledigt. In meinem Fall habe ich mich für das xwiki-tomcat9-mariadb Paket entschieden, dass nicht nur XWiki sondern, wie auch der Name schon vermuten lässt Tomcat 9 und die Anbindung an MariaDB mitbringt.

Nach einem ersten Upgrade ist mir nun allerdings aufgefallen, dass ich keinerlei Seiten mehr bearbeiten konnte, da laut Fehlermeldung kein "Lock" der Seite stattfinden konnte. Nach kurzer Recherche stellte sich heraus, dass Tomcat nicht weiß, dass nginx per SSL läuft. Daher kurz und knapp alle Punkte, die nötig sind, damit XWiki mit nginx und SSL genutzt werden kann. Dies ist meiner Meinung nach in der offiziellen Doku leider etwas unübersichtlich.

In der Datei /etc/tomcat9/server.xml nach folgender Zeile suchen:

<Engine name="Catalina" defaultHost="localhost">

Und dort drunter folgenden Part ergänzen:

    <Valve className="org.apache.catalina.valves.RemoteIpValve"
      internalProxies="127\.0\.[0-1]\.1"
      remoteIpHeader="x-forwarded-for"
      requestAttributesEnabled="true"
      protocolHeader="x-forwarded-proto"
      protocolHeaderHttpsValue="https">
    </Valve>

Weiter geht es in der /etc/xwiki/xwiki.cfg, dort folgende Zeile einkommentieren:

xwiki.url.protocol=https

Ich möchte schöne, kurze URLs haben. Standardmäßig hängt XWiki hinter die URL noch ein /xwiki. Dies lässt sich wie folgt entfernen:

Die XWiki Config vom Tomcat umbennen:

mv /etc/tomcat9/Catalina/localhost/xwiki.xml /etc/tomcat9/Catalina/localhost/ROOT.xml

In /etc/xwiki/xwiki-tomcat9.xml suchen nach:

<Context path="/xwiki" docBase="/usr/lib/xwiki"
         containerSciFilter="org.apache.tomcat.websocket.server.WsSci|org.apache.jasper.servlet.JasperInitializer">

und bei Context path /xwiki durch / ersetzen.

Abschließend noch meine nginx-Config:

server {
    listen [::]:443 ssl http2;
    listen 443 ssl http2;
    server_name wiki.deineDomain.de;

    root /var/www/html;

    # Configuration to avoid Request Entity too large error 413
    client_max_body_size 0;
    ssl_certificate /etc/letsencrypt/deineDomain/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/deineDomain/key.pem;

    access_log /var/log/nginx/wiki.deineDomain.access_ssl.log;
    error_log /var/log/nginx/wiki.deineDomain.error_ssl.log;

    location / {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Scheme $scheme;
        proxy_redirect off;
        if (!-f $request_filename) {
            proxy_pass http://127.0.0.1:8080;
            break;
        }
    }

    location ~ /.well-known {
        allow all;
    }
 }

Dienste neustarten

systemctl restart tomcat9.service
systemctl restart nginx

Fertig.

Manchmal möchte man ein Lied oder eine Playlist abspielen, die man nicht lokal in der mpd-Datenbank hat. Häufig findet man diese Lieder dann bei youtube. Da ich über meinen mpd mittels snapcast Musik gleichzeitig in mehreren Räumen abspielen kann möchte ich natürlich mpd auch für youtube nutzen.

Dazu habe ich mir ein kleines script geschrieben, welches das Lied oder die Playliste mit mpd abspielt.

Vorraussetzungen um das script nutzen zu können sind mpc und yt-dlp oder youtube-dl.

#! /bin/bash

# mpdpipe
# Copyright (C) 2021 Martin Dosch 
# 
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
# 
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <https://www.gnu.org/licenses/>.

ytdl=$(command -v yt-dlp)
if [[ -z "$ytdl" ]]
then
	ytdl=$(command -v youtube-dl)
	if [[ -z "$ytdl" ]]
	then
		echo "No youtube-dl found."
		exit
	fi
fi

mpc=$(command -v mpc)
if [[ -z "$mpc" ]]
then
	echo "No mpc found."
	exit
fi

get_song_url () {
	url=$("$ytdl" -qgf bestaudio "$1")
}

check_url () {
	regex='(https?|ftp|file)://[-A-Za-z0-9\+&@#/%?=~_|!:,.;]*[-A-Za-z0-9\+&@#/%=~_|]'
	if [[ ! $1 =~ $regex ]]
	then
		echo "$1 is not a valid URL."
		exit
	fi
}

show_help () {
	basename=$(command -v basename)
	if [[ -z "$basename" ]]
	then
		program="$0"
	else
		program=$($basename "$0")
	fi
	echo "Usage:"
	echo "$program url"
	echo "$program mpd_host url"
	exit
}

case $# in
	1)
		if [ "$1" = "help" ] || [ "$1" = "--help" ]
		then
			show_help
		fi
		if ! $mpc -q
		then
			echo "Couldn't connect to mpd."
			exit
		fi
		mpc_command="$mpc"
		input="$1"
		;;
	2)
		if ! $mpc -qh "$1"
		then
			echo "Couldn't connect to mpd at $1."
			exit
		fi
		mpc_command="$mpc -h $1"
		input="$2"
		;;
	*)
		echo "Invalid input."
		show_help
		;;
esac

check_url "$input"

$mpc_command clear
firstrun=1

for link in $("$ytdl" --flat-playlist --no-warnings -qg "$input")
do
	get_song_url "$link"
	if [ -n "$url" ]
	then
		$mpc_command add "$url"
		if [ $firstrun -eq 1 ]
		then
			$mpc_command play
			firstrun=0
		fi
	fi
done

Ich werde das script hier aktuell halten, aber für den Fall, dass ich es doch mal vergesse: Ich habe es auch auf salsa.debian.org veröffentlicht.

#! /bin/bash

# mpdpipe
# Copyright (C) 2021 Martin Dosch 
# 
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
# 
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see .

ytdl=$(command -v yt-dlp)
if [[ -z "$ytdl" ]]
then
	ytdl=$(command -v youtube-dl)
	if [[ -z "$ytdl" ]]
	then
		echo "No youtube-dl found."
		exit
	fi
fi

mpc=$(command -v mpc)
if [[ -z "$mpc" ]]
then
	echo "No mpc found."
	exit
fi

get_song_url () {
	url=$("$ytdl" -qgf bestaudio "$1")
}

check_url () {
	regex='(https?|ftp|file)://[-A-Za-z0-9\+&@#/%?=~_|!:,.;]*[-A-Za-z0-9\+&@#/%=~_|]'
	if [[ ! $1 =~ $regex ]]
	then
		echo "$1 is not a valid URL."
		exit
	fi
}

show_help () {
	basename=$(command -v basename)
	if [[ -z "$basename" ]]
	then
		program="$0"
	else
		program=$($basename "$0")
	fi
	echo "Usage:"
	echo "$program url"
	echo "$program mpd_host url"
	exit
}

case $# in
	1)
		if [ "$1" = "help" ] || [ "$1" = "--help" ]
		then
			show_help
		fi
		if ! $mpc -q
		then
			echo "Couldn't connect to mpd."
			exit
		fi
		mpc_command="$mpc"
		input="$1"
		;;
	2)
		if ! $mpc -qh "$1"
		then
			echo "Couldn't connect to mpd at $1."
			exit
		fi
		mpc_command="$mpc -h $1"
		input="$2"
		;;
	*)
		echo "Invalid input."
		show_help
		;;
esac

check_url "$input"

$mpc_command clear
firstrun=1

for link in $("$ytdl" --flat-playlist --no-warnings -qg "$input")
do
	get_song_url "$link"
	if [ -n "$url" ]
	then
		$mpc_command add "$url"
		if [ $firstrun -eq 1 ]
		then
			$mpc_command play
			firstrun=0
		fi
	fi
done

GrapheneOS ist ein Custom ROM, aber nicht irgendeines. Die Entwickler behaupten ein besonders sicheres Custom ROM auszuliefern und bieten dieses auch nur für Hardware an, die besondere Sicherheitsstandards erfüllt. Doch könnte man nicht was anderes verwenden?

Vor Kurzem berichtete ich bereits von meinem Plan, GrapheneOS einzusetzen. Nachdem nun die ersten experimentellen Builds für das Google Pixel 6 zur Verfügung stehen, möchte ich die Serie zu GrapheneOS beginnen. Zuerst ist daher die Frage zu klären, warum man kein anderes ROM oder Betriebssystem nehmen kann. Es gibt schließlich zahlreiche proprietäre und quelloffene Systeme.

Wenn Herstellersoftware, dann Apple

Man sollte sich nichts vormachen, jede Modifikation am Betriebssystem, selbst wenn es so professionell dokumentiert ist wie GrapheneOS, bedeutet für die meisten Menschen einen zu großen Aufwand. Hier fehlt die Zeit, das Interesse, die Kenntnisse oder eine Kombination aus allem.

Wenn man keine Modifikation am System vornehmen möchte, jenseits der Veränderung irgendwelcher Einstellungen oder Installation von Apps, dann empfehle ich nach wie vor iPhones. Diese sind nicht perfekt, es fließen immer noch Daten an Apple ab und man ist von den Entscheidungen in Cupertino abhängig, aber man bekommt ein ganz passables Datenschutzniveau und die Geräte sind sehr sicher. Die extrem geschlossene Plattform hat eben auch Vorteile und nicht nur Nachteile.

Der Vorteil von Apples iOS ist somit lediglich relativ und liegt vor allem daran, wie schlecht Android in der Variante ist, wie wir es bei auslieferten Geräten vorfinden (genannt Stock Android). Stock Android bedeutet in der Regel nicht nur massiven Datenabfluss an Google, sondern auch an mindestens einen weiteren Hersteller. Angesichts der gegenwärtigen Marktanteile sogar oft ein chinesischer Anbieter und damit an ein Unternehmen, das zwangsläufiger Teil des größten, restriktivsten und immer übergriffigeren Überwachungsstaates der Welt ist. Hinzu kommen ungelöste Probleme bei der Updateversorgung, strukturelle Probleme im System etc. pp. Stock Android ist der Traum für jeden Produzenten von bösartiger Software – vom gewöhnlichen Kriminellen bis hin zu staatlichen Akteuren.

Warum nicht LineageOS, Murena (/e/) oder eine andere ROM?

Der Datenschutz macht es somit unumgänglich sich von Stock Android und den proprietären Google-Bestandteilen von Android zu lösen. Das ist nur leider gar nicht so einfach. Ist man bereit, ein alternatives System (eine sogenannte Custom ROM) zu installieren, gibt es zahlreiche Alternativen. Es waren früher mal mehr, aber noch immer gibt es – abhängig vom jeweiligen Gerät – ein paar verschiedene Systeme zur Auswahl. Leider sind diese allesamt nicht nur positiv, vor allem wenn man den Sicherheitsaspekt in den Vordergrund stellt.

Alle diese Custom ROMs basieren auf dem Android Open Source Project (AOSP) und passen dieses an. Eine Zusammenstellung der wichtigsten Begriffe habe ich hier mal erstellt. Die bekannteste Variante ist immer noch LineageOS und dieses bildet auch die Basis für viele andere ROMs. Nur sehr wenige ROMs basieren direkt auf AOSP. Hier ist wichtig sich zu vergegenwärtigen, dass die Modder-Szene nicht automatisch an Datenschutz und Sicherheit interessiert ist. Die Verbindung beider Interessengruppen ist eher ein Zweckbündnis. Vieles von dem, was auf XDA Developers so passiert (fehlende Offenlegung des Codes, Rooten, Bootloader öffnen, Software aus zweifelhaften Quellen via Downloadlink zu einem Filehoster beziehen) widerspricht Datenschutz und Sicherheit.

Das hat verschiedene Probleme zur Folge. Solche, die LineageOS-spezifisch sind und die sich durch die meisten ROMs ziehen und negative Auswirkungen auf die Sicherheit durch die Nutzung eines Custom ROM allgemein.

Die LineageOS-spezifischen Probleme sind mannigfaltig und sowohl technischer als auch organisatorischer Natur. Das Projekt hat – zählt man CyanongenMod dazu – eine lange Entwicklungsgeschichte hinter sich und passt AOSP seit vielen Jahren mit vielfältigen Erweiterungen an. Dabei hat man einige hartnäckige Probleme und Bugs ins System getragen, die man nicht beheben kann oder möchte. XDA Developers ist voll von entsprechenden Berichten über hartnäckige Neustart-Probleme und vieles andere. Hier kann man betroffen sein, muss aber nicht. Das ist auch abhängig vom Gerät. Hinzu kommt eine dünne Entwicklerdecke, die das Mehraugenprinzip als zentrales Sicherheitsprinzip von Open Source unterminiert. Schaut man sich die Änderungen im Code an, stößt man oft auf Commits, bei denen ein und derselbe Entwickler die Änderung vorgenommen, den Review durchgeführt und die Verifizierung abgenommen hat. Vor allem im Bereich der Geräteunterstützung ist das keine Seltenheit. Je kleiner das ROM, desto größer das Problem.

Hinzu kommen Probleme, die jenseits der Möglichkeiten von LineageOS & Co sind. Updates beziehen sich immer nur auf AOSP. Firmware und Kernel müssen vom Hersteller aktualisiert werden. Stellt der Hersteller den Support ein, ist es mit Kernel-Updates nicht mehr weit. Firmware-Updates müssen zudem am System vorbei vorgenommen werden. Das ist keineswegs trivial und passiert deshalb oft nicht. Angesichts der zentralen Bedeutung von Firmware, können dadurch Geräte scheunentorgroße Sicherheitslücken aufweisen. Naturgemäß muss man zudem seinen Bootloader öffnen und ein Custom Recovery installieren. Das System wird dadurch für einen Angreifer unsicherer als ein Stock Android (zur Erinnerung: Datenschutz ungleich Sicherheit).

Das gilt auch für das aktuell sehr populäre Murena (zuvor /e/) und andere LineageOS-Abkömmlinge und sorgt letztlich für den Ausschluss nahezu aller Custom ROMs.

Eine Alternative wäre lediglich CalyxOS, das eine ähnliche Zielsetzung wie GrapheneOS verfolgt, es dem Anwender aber etwas leichter machen soll. CalyxOS ist vor allem für jene Anwender von Interesse, die auf microG wert legen, was mir aber nicht auf das Gerät kommt.

Und Linux? Wann steht das endlich zur Verfügung?

Seitdem ich mich mit Smartphones befasse warte ich auf ein „richtiges“ Linux für Smartphones. Es ist so traurig, aber die Zustandsbeschreibung, die ich 2018 schrieb, gilt eigentlich immer noch.

Linux scheitert mobil daran, dass dort alle negativen Eigenschaften der Community zum tragen kommen und keine der positiven. Zersplitterte Projekte ohne wirtschaftliche Perspektive basteln nebeneinander her und anstelle die neue Geräteklasse zu nutzen, um überholte Strukturen abzulösen, übertragt man die alten Pfadabhängigkeiten des Desktop-Ökosystems auf die mobilen Geräte. Zahlungskräftige Sponsoren fehlen zudem fast vollständig und somit ist Linux im Mobilbereich ein interessantes Beispiel dafür, was passiert, wenn die so oft schutzartig vorgebrachte Ehrenamtlichkeit der Entwicklung tatsächlich mal eintritt: Nicht viel!

Anstelle hier wenigstens aufzuholen, verliert man ganz im Gegenteil immer stärker den Anschluss. Möglicherweise ist man hier bereits endgültig abgehängt, da wird sich substanziell aller Voraussicht nach nichts mehr ändern. Und selbst wenn da noch was kommt, erfüllt es zwar das Kriterium Open Source, aber hinsichtlich elementarer Sicherheitsfunktionen, die sich in den letzten Jahren auf diversen Plattformen eingebürgert haben, hinkt man technisch weit hinterher. Wie eben der Desktop auch.

Diese Problembeschreibung gilt auch für Systeme wie Sailfish OS, das im Gegensatz zu AOSP nicht mal komplett quelloffen ist und bei dem sich die Entwicklerfirma Jolla zudem inzwischen in fragwürdiger finanzieller Abhängigkeit von Russland befindet. Damit ist das absolut keine Option.

Zusammenfassung und Ausblick

Diese Zustandsbeschreibung ist für langjährige Leser dieses Blogs sicher nicht neu, sondern zieht sich durch meine Artikel zu dem Thema. Dazu erhalte ich Widerspruch und interessante Kommentare. In einem jener Kommentare legte man mir GrapheneOS nahe, das viele der Schwächen von Custom ROMs umgeht und ein besonders sicheres System liefert. Ein Überblick über GrapheneOS folgt im nächsten Teil der Serie.

Der Artikel GrapheneOS – Warum kein anderes System? erschien zuerst auf [Mer]Curius

Viele Datenschützer nutzen Android Custom ROMs, um der Überwachung durch Hersteller zu entgehen. Leider fehlen diese einige heute übliche Funktionen wie Push Dienste. Deshalb empfehlen viele gerne microG. Ein Fehler?

Ich persönlich benötige diese Dienste nicht und nutze deshalb kein microG. Die Frage, welchen Mehrwert für Privatsphäre und Datenschutz microG bietet, hatte ich hier aber auch schon gestellt.

microG bewirbt das eigene Produkt wie folgt auf der Webseite:

Although most microG components are far from complete, users are amazed by the results. Free software users got extended application support, privacy-caring users can reduce or monitor data that is sent to Google and especially older phones can expect some battery life improvements. microG is not only used on real devices, but also replaces Google tools in test emulators and is even used in virtual mobile infrastructure.

microG, abgerufen am 04.12.2021 (Hervorhebung durch den Autor)

Die Gleichsetzung von Open Source mit positiven Effekten für Privatsphäre und Datenschutz als Werbestrategie ist hier mal wieder ein beliebtes, aber gefährliches Mittel.

Denn der Mehrwert für Privatsphäre und Datenschutz ist nicht besonders positiv. Das ist jedenfalls die Meinung der GrapheneOS-Entwickler, wie man im September in einem Thread auf Twitter darlegte:

Da viele Leser hier Twitter nicht nutzen möchte, fasse ich die Kernaussagen knapp zusammen:

• microG ist keine Open Source Implementierung, der App Dienste, da die darauf zugreifenden Apps weiterhin proprietäre Google-Bibliotheken nutzen.
• microG ist somit nur ein Open Source Zwischenhändler zwischen proprietären Bibliotheken und proprietären Diensten. Das bietet keinen Mehrwert für Privatsphäre und Sicherheit.
• Sie sind faktisch sogar unsicherer als die proprietäre Play Service-Implementierung, weil das API Sicherheitsmodell nicht richtig umgesetzt ist und Techniken wie Pinning nicht implementiert sind.
• Die Nutzung von microG erfordert die Umgehung von Sicherheitsprüfungen und Play Services Signaturen.
• Die Verwendung von microG kann nur durch eine invasiven Eingriff in das Betriebssystem erfolgen und setzt umfassenden Zugriff auf privilegierte APIs und spezielle SELinux-Richtlinien vorraus.

Meiner Meinung nach trifft damit auf microG die Bezeichnung „Snake oil/Schlangenöl“ zu. Die meisten kennen das bestimmt aus dem Kontext von Antiviren-Programmen. Es handelt sich per Definition um ein völlig wirkungsloses „Wundermittel“, das anstelle zu helfen sogar unerwünschte Nebenwirkungen haben kann. Genau das scheint nach Aussage der GrapheneOS-Entwickler, deren Expertise klar sein dürfte, auf microG zutreffen.

Bei GrapheneOS arbeitet man stattdessen an sogenannten „Sandboxed Play Services„. Letztlich scheint das eine sinnvollere Variante zu sein. Entweder man kann auf Google-Technologien verzichten oder nicht. Wenn man sie benötigt, hilft auch keine vorgeblich freie Reimplementierung in Open Source, da man Bibliotheken in den Apps und die proprietäre Serversoftware bei Google trotzdem nicht kontrolliert. Man verschafft sich damit bestenfalls die Illusion von Datenschutz und vielleicht ist das sogar kontraproduktiv für die Sicherheit des Geräts.

Der Artikel Ist microG nichts anderes als Schlangenöl? erschien zuerst auf [Mer]Curius

Im Blog schreibe ich regelmäßig über unterschiedliche Betriebssysteme und versuche gerne den normalen Nutzer im Blick zu behalten. In der Community kursieren dazu manchmal komische Vorstellungen. Deshalb man ein Blick auf die Fakten.

Nicht nur beim Thema Betriebssysteme gibt es bei vielen „gefühlte Wahrheiten“, die sich aus dem persönlichen Nutzungsverhalten und dem, was man so in seinem Umfeld sieht, ergibt. In der Linux-Community kursieren da manchmal lustige Annahmen, wenn einige behaupten, Linux müsste doch bestimmt 10 % Marktanteil haben oder mobil wären Custom ROMs eine relevante Größe. Solche verzerrten Wahrnehmungen gibt es aber natürlich auch in anderen Communitys.

Eine Möglichkeit an Zahlen zu kommen, bietet Statista. Dabei handelt es sich um ein deutsches Unternehmen, das Daten zu vielen verschiedenen Themen zusammen trägt und aufbereitet. Einige Informationen sind kostenlos, für andere benötigt man eine kostenpflichtige Lizenz. Wer hier als Mitarbeiter oder Student Angehöriger einer Universität ist, kann mal schauen, ob es dafür eine Campuslizenz gibt.

Die Zahlen sind nicht perfekt, sondern werden unter anderem über Millionen Page Views erhoben und aus Lizenzgründen kann ich die genauen Zahlen und Grafiken hier im Blog nicht übernehmen, aber möchte mal eine Trends verdeutlichen und mit Zahlen aus anderen Quellen anreichern, um mal eine gemeinsame Diskussionsgrundlage herzustellen.

Desktopsysteme

Alle Hersteller arbeiten an konvergenten Systemen und Desktop und Smartphone / Tablet nähern sich sukzessiv an, aber noch macht es Sinn, in Desktop- und Mobilbetriebssystem zu trennen.

Am Desktop hält Microsoft mit Windows knapp 75 % des weltweiten Marktanteils, gefolgt von macOS mit ca. 15 % und dann erst Linux mit knapp über 2 % (Statista). Deutschland ist da erstaunlich nahe an den weltweiten Werten (Statista), anders als beispielsweise die USA. Dort hält Windows nur noch knapp 60 %, dafür kommt macOS auf fast 25-30% und Googles ChromeOS kommt hier auf ca. 8 %. Linux hat weniger als 2 % und ist sogar leicht rückläufig (Statista), wobei man das bei so kleinen Marktanteilen sicher schwer zu erheben ist.

Alles Humbug? Mit Steam erhebt eine weitere Stelle umfassend Daten und da sieht das sogar noch besser für Windows aus. Zuletzt kam Microsofts Betriebssystem auf knapp 96 % und macOS kommt auf lediglich 2,70 % und Linux nur auf 1,16 %.

Bei Statista kann man die Erhebung kritisieren, bei Steam den Fokus auf Gamer mit ihrer Präferenz für Windows. Man kann aber auch einfach konstatieren, dass Linux in keiner mir bekannten Erhebung auf mehr als 2-4 % kommt und dieser Marktanteil konstant bis rückläufig ist.

Mobile Geräte

Der Markt an mobilen Betriebssystemen war mal sehr vielfältig. 2010 tummelten sich dort zwar schon iOS und Android, aber daneben gab es noch BlackBerry, Windows Phone, Nokia Symbian und andere Nischensysteme. Das war eigentlich ein idealer Zustand. Heute gibt es hingegen nur noch Apples iOS und Googles Android.

Die Verteilung ist je nach Land aber sehr unterschiedlich. Da spielt vermutlich die unterschiedliche Kaufkraft und unterschiedliche Traditionen eine Rolle. In den USA ist der Markt z. B. fast 50/50 zwischen iOS und Android geteilt, während in Spanien Android komplett dominant ist (Statista). Deutschland nimmt da eine Zwischenposition ein, verzeichnet aber tendenziell einen steigenden Marktanteil für iOS (Statista).

Innerhalb von Android hat Google nach wie vor Probleme mit der Updateverteilung. Ein substanzieller Teil der Nutzer hängt auf älteren Android-Versionen, selbst das jetzt schon wieder veraltete Android 11 kommt erst auf knapp 1/3 Marktanteil (Statista). Custom ROMs spielen dabei überhaupt keine Rolle. Die bekannteste und größte Custom ROM LineageOS hat laut eigenen Angaben 1.865.014 aktive Gerät (Stand 04.12.2021). Zum Vergleich: Pro Quartal werden weltweit knapp 300 Mio. Smartphones verkauft (Statista).

Andere Systeme wie SailfishOS oder die Linux-Systeme (wenn man Android nicht dazu zählt) spielen keine messbare Rolle.

Schlussfolgerungen

Warum diese Zahlenorgie? Manchmal gibt es in Communitys eine verzerrte Binnenwahrnehmung und je kleiner die Community, desto eher entsteht eine geschlossene Blase. Daraus folgen dann bei manchen „gefühlte Wahrheiten“.

Die Marktanteile zeigen, dass Linux nicht sonderlich erfolgreich (Desktop) oder gar nicht existent (Mobil) ist. Viele Linux-Anwender werden das nicht mal als Manko wahrnehmen. Apple geling es hingegen seinen Marktanteil langsam aber stetig zu steigern, das Beispiel ChromeOS in den USA zeigt übrigens, dass die Marktanteile nicht so fest gefügt sind, wie manche es als Grund für den ausblenden Erfolg von Linux anführen. Das sagt übrigens nichts über den Erfolg von Open Source, denn freie Software kommt auch bei Windows oder macOS eine herausragende Bedeutung zu. Nicht umsonst widmen Projekte wie KDE der Windows Plattform mehr Aufmerksamkeit.

Diese Zahlen sollte man aber im Hinterkopf haben, wenn man sich über den Erfahrungsraum und Erwartungshorizont normaler Nutzer Gedanken macht und sich überlegt, wo man diese beispielsweise bei den Themen Datenschutz oder Privatsphäre abholen muss.

Der Artikel Betriebssysteme – Verbreitung und Marktanteile erschien zuerst auf [Mer]Curius

Fr, 3. Dezember 2021, Niklas

Bereits Mitte Mai haben wir berichtet, dass das freie Betriebssystem Haiku auf die RISC-V CPU Architektur portiert wurde. Seitdem wurde noch viel daran gearbeitet. Zum Beispiel wurde das System auf echter Hardware getestet, dazu bekam der Entwickler ein HiFive Unmatched RISC-V Mainboard von der Haiku Inc. zur Verfügung gestellt.

Die Änderungen dazu hat der verantwortliche Entwickler zunächst in einem eigenen Fork des Haiku Quellcodes vorgenommen. In der Zwischenzeit wurden viele Stellen im Code optimiert und er wurde in den Master Branch von Haiku selbst übernommen. Das bedeutet, dass die Nightly Builds jetzt funktionsfähig sind und ausprobiert werden können.

Man sollte dabei im Hinterkopf behalten, dass zunächst nur die x86 Architektur voll unterstützt wird, RISC-V zählt weiterhin als experimentell. Auch sind noch keine Paket-Repositorys für die RISC-V Variante vorhanden, sodass alle Pakete selbst über den Haikuporter und das Haikuports Quellcode-Repository kompiliert werden müssen.

Wer das Experiment trotzdem wagen möchte, kann Haiku jetzt auf RISC-V ausprobieren. Als echte Hardware wird bislang nur das HiFive Unmatched unterstützt. Wer dieses nicht besitzt, kann auch mittels QEMU auf einem ganz normalen x86 Computer ein RISC-V System emulieren. Und so funktioniert es:

HiFive Unmatched:

• Anforderungen:
  • HiFive Unmatched Mainboard
  • Eine AMD Radeon Grafikkarte, die von Haikus radeon_hd Treiber unterstützt wird
  • Eine SD-Karte, die als u-boot uefi bios vorbereitet wurde
  • Haiku RISC-V Nightly Build auf einem USB-Stick
• Vorgehensweise:
  • SD-Karte in das HiFive Unmatched einstecken
  • USB-Stick in das HiFive Unmatched einstecken
  • Das HiFive Unmatched einschalten
  • Ein Desktop sollte innerhalb von einer bis zwei Minuten erscheinen

Serielles Debugging: Sollte es hierbei Probleme geben, kann ein Micro-USB-Kabel mit dem HiFive Unmatched verbunden werden. Dadurch sieht man serielles Output während des Bootvorgangs. (minicom, 115200 8N1, no flow control)

QEMU:

• Anforderungen:
  • QEMU 6.0.0 oder neuer
  • Haiku RISC-V Nightly Build
  • u-boot binary für QEMU riscv64

Haiku kann mit dem folgenden Befehl in QEMU gestartet werden:

qemu-system-riscv64 -M virt -m 1G -device ati-vga -kernel u-boot.bin \
    -drive file=haiku-mmc.image,format=raw,if=virtio \
    -usb -device usb-ehci,id=echi -device usb-kbd -device usb-tablet

Serielles Output kann auf unter view → serial0 angeschaut werden.
Der Haiku Desktop erscheint auf view → ati-vga. Achtung: Eine Boot-Animation gibt es nicht. Hier erscheint erst etwas, wenn der Bootvorgang abgeschlossen ist.

Vorsicht vor Bugs: Es gibt einige bekannte Probleme mit RISC-V in Verbindung mit QEMU. Wenn der Bildschirm über längere Zeit schwarz bleibt, sollte man es einfach noch einmal versuchen. Relevante Bugs: #17379 und #17380

RISC-V ist Haikus erster funktionierender Port auf eine andere CPU Architektur. Es ist für das Projekt eine grosse Chance, die Hardwareunterstützung zu erweitern. Viel Arbeit ist allerdings noch zu tun. So kann Haiku auf RISC-V beispielsweise aktuell nur einen einzigen CPU Kern nutzen.

Auch interessant: In letzter Zeit wird wieder vermehrt an den Portierungen auf ARM gearbeitet, sowohl an 32Bit als auch 64Bit. Diese Ports sind noch lange nicht so weit wie RISC-V und sind zum aktuellen Zeitpunkt nicht nutzbar, aber in ein paar Monaten könnten die ersten funktionierenden Builds für Experimentierfreudige bereitstehen.

Quelle: https://www.haiku-os.org/blog/kallisti5/2021-11-07_booting_our_risc-v_images/

Do, 2. Dezember 2021, Lioh Möller

Das Manjaro Linux ARM Entwicklerteam hat eine erste Beta-Version für das PinePhone Pro vorgestellt. Dabei kommt der auf GNOME basierende Desktop Phosh in Version 0.14 zum Einsatz, die darunterliegenden GNOME Komponenten basieren auf Version 41.1 der Desktopumgebung.

Im Gegensatz zur Version für das reguläre PinePhone, basieren die Abbilder für das PinePhone Pro auf dem Linux Kernel 5.16-rc.

Darüber hinaus wurde systemd 249.7 und Mesa 21.2.5 integriert. Das Anti-Spam-System erlaubt es ungewünschte Anrufe zu unterdrücken.

Download: https://github.com/manjaro-pinephone/phosh/releases

Do, 2. Dezember 2021, Ralf Hersel

NixOS 21.11 trägt den Namen "Porcupine" und erscheint sechs Monate nach der Veröffentlichung von NixOS 21.05 "Okapi". Es enthält eine Menge Neuheiten, angefangen bei der GNOME 41.1 Desktop-Umgebung für die GNOME-Edition, über Wayland-Unterstützung für die KDE Plasma 5.23 Edition bis hin zur Version 6 des Pantheon-Desktops von elementary OS.

Wer mehr über diese spezielle GNU/Linux-Distribution erfahren möchte, dem empfehlen wir unsere vierteilige Serie zu NixOS.

Diese Version enthält Nix 2.3.16 als Standard-Paketmanager, stellt das iptables-Dienstprogramm auf das nf_tables-Backend um, aktualisiert das Hadoop-Modul und -Paket auf Hadoop 3 als Standard mit neuen Diensten wie JournalNode, ZKFS und HTTPFS und verbessert die LXD-Unterstützung, um Images direkt aus Konfigurationen zu erstellen.

Eine weitere interessante Änderung in NixOS 21.11 ist die Unterstützung für die Ausführung von Aktivierungsskripten während eines nixos-rebuild dry-activate und die Erkennung der Trockenaktivierung durch das Auslesen der Variable $NIXOS_ACTION.

"Damit können Aktivierungsskripte ausgeben, was sie ändern würden, wenn die Aktivierung wirklich ausgeführt würde. Das users/modules-Aktivierungsskript unterstützt dies und gibt einen Teil seiner Aktionen aus", erklären die Entwickler.

In dieser Version sind standardmässig PHP 8.0, Python 3.9, systemd 249, GNU Bash 5, OpenSSH 8.8p1, kops 1.21.1, PostgreSQL 13, spark 3, kubernetes-helm 3.7.0 und ORY Kratos 0.8.0 Alpha 3 enthalten. Unter der Haube wird NixOS 21.11 von der Linux 5.10 LTS Kernel-Serie angetrieben (Linux 5.10.81 ist der Standard-Kernel).

Zu guter Letzt bringt NixOS 21.11 zahlreiche neue Dienste mit, darunter btrbk für die Sicherung von btrfs-Subvolumes, clipcat X11-Clipboard-Manager, PeerTube, eine freie und dezentrale Alternative zu Video-Hosting-Plattformen, Hockeypuck OpenPGP-Schlüsselserver und viele andere, die man in den Release Notes findet.

NixOS 21.11 kann als GNOME- oder KDE-Plasma-Live- und installierbare ISO-Images sowie ein Minimal-ISO-Image ab sofort von der Webseite des Projekts heruntergeladen werden. Während die GNOME- und KDE-Plasma-ISOs nur 64-Bit-Systeme unterstützen, kann das Minimal-Image auch auf 32-Bit-Rechnern installiert werden.

Quelle: https://9to5linux.com/nixos-21-11-porcupine-released-with-gnome-41-kde-plasma-on-wayland

Mi, 1. Dezember 2021, @65536@troet.cafe

Im letzten Teil unserer Artikelserie zu NixOS fassen wir zusammen, für wen NixOS geeignet ist und für wen möglicherweise auch eher nicht. Die ersten drei Teile befassen sich unter anderem mit den Grundlagen eines deklarativen Betriebssystems, der Installation und Konfiguration von NixOS sowie den Besonderheiten der Paketverwaltung.

NixOS könnte gut geeignet sein für diejenigen, die…

• gerne sehr detaillierte Kontrolle über ihr System haben möchten.
• ein sauberes System haben möchten, auf dem früher getätigte Einstellungen nicht vergessen werden können und später zu Problemen führen, weil sie zentral und deklarativ gesetzt werden. Wer wie ich den deklarativen, anti-imperativen Ansatz auf die Spitze treiben will, kann sogar die Dateisystemwurzel bei jedem Neustart leeren und neu deklarativ generieren lassen, beispielsweise indem sie als tmpfs eingerichtet wird.
• ein besonders zuverlässiges System haben wollen. Der Nix-Paketmanager verhindert prinzipbedingt, Konflikte von Paketen sehr gut.
• viel herumexperimentieren möchten, ohne ihr System in Probleme zu manövrieren. Mit nix-shell lassen sich Programme ausprobieren, ohne sie zu installieren. Ich bin mehrmals zwischen Gnome und KDE gewechselt, indem ich einfach die Zeilen zur Desktopumgebung und dem Displaymanager in configuration.nix austauschte. Ein sudo nixos-rebuild boot und einen Reboot später landete ich ohne jegliche Fehler oder weitere Umstände im anderen Displaymanger und in der anderen Desktopumgebung. Nicht einmal die in Gnome und KDE jeweils integrierten Anwendungen müllten die andere zu. Auch auf das Rollback trifft das tadellos zu.
• Anwendungsprogramme benutzerweise installierbar haben möchten. Jeder Benutzer kann mit nix-env selbst Software installieren, ohne dabei Administratorrechte zu benötigen. Die Software steht dann nur dem einen Nutzer zur Verfügung.
• mehrere Rechner möglichst identisch konfigurieren wollen, indem dieselbe Konfigurationsdatei auf alle Rechner angewandt wird.
• zukünftig neue Rechner mit derselben Software und Einstellungen einrichten wollen wie ihren derzeitigen. Anstatt entweder sämtliche installierte Software herauszufinden und nachzuinstallieren oder ein Systemimage komplett zu klonen und damit auf eine frische Linuxinstanz zu verzichten, kann schon bei der Installation einfach die bisherige Konfiguration eingefügt und nur ggf. die hardwarespezifischen Zeilen aus der automatisch generierten Konfiguration übernehmen.

NixOS ist möglicherweise weniger geeignet für diejenigen, die…

• lieber mit GUI-Werkzeugen arbeiten als mit Konfigurationsdateien und Befehlen. In der Alltagsbenutzung wird man zwar weitestgehend ohne Kommandozeile auskommen, aber für die Installation und Teile der Konfiguration ist sie nötig.
• zum allerersten Mal Linux nutzen. In dem Fall ist es allerdings unwahrscheinlich, dass man ausgerechnet NixOS ins Auge gefasst hat.
• den imperativen Ansatz bevorzugen. Er ist zwar zu grossen Teilen auch mit NixOS möglich, empfohlen ist hier aber deklarative Vorgehensweise.
• nicht die Motivation haben, sich die bei NixOS neu zu lernenden Dinge anzueignen. Die Lernhürde ist nicht zu unterschätzen, aber andererseits auch nicht immens und definitiv lohnend. Nach einem knappen Jahr des Linux-Kennenlernens mit Debian wechselte ich zu NixOS und brauchte dann 10-20 Abendstunden, um mich mit den Eigenheiten von NixOS zurechtzufinden. Seitdem möchte ich das deklarative Konzept nicht mehr missen, und lerne immer mehr tolle Optionen kennen.
• sehr wenig Speicherplatz haben.

Ein paar der Alternativen zu NixOS sind:

• Fedora Silverblue: Diese sehr benutzerfreundliche Distribution ist immutable, es sind also, wie übrigens auch bei NixOS, die meisten Systemdateien im Betrieb unabänderbar. Neue Anwendungen sind als Flatpak zu beziehen; die selten nötigen Änderungen am Basissystem erfordern bei Silverblue sogar immer einen Neustart. Die Ähnlichkeiten zu NixOS sind die integrierten Rollbacks-Bootoptionen und die hohe Zuverlässigkeit durch Sauberhaltung des Systems. Die Immutabilität bei NixOS ist weniger strikt als bei Silverblue, letzteres hat aber keine zentrale deklarative Konfiguration. Statt der nix-shell ist hier das Werkzeug toolbx zum Nutzen nicht ins System integrierter Software verfügbar.
• Fedora Kinoite: Der jüngere Bruder von Fedora Silverblue nutzt KDE Plasma statt Gnome.
• GNU Guix System: Von NixOS inspiriert, setzt diese besonders auf freie Software fokussierte Distribution die gleichen Konzepte mit eigenen Implementierungen und Werkzeugen um. Ausserdem setzt es statt systemd GNU Daemon Shepherd als sein Init-System ein. Diese Distribution wird auch von der FSF empfohlen.

Ein paar Fun Facts. Schon gewusst, dass…

• NixOS eine Variante für Mobilgeräte hat? Leider werden recht wenige Geräte unterstützt.
• die Softwarerepositories von Nix sowohl zu den grössten als auch aktuellsten der Linuxwelt gehören?
• der Nix-Paketmanager auch auf vielen anderen Distributionen, und sogar auf Apples MacOS installierbar ist? Das bringt diesen zwar nicht die Reproduzierbarkeit und Konfigurierbarkeit von NixOS, aber zumindest nix-env, nix-shell etc.

Links:

https://nixos.org/
https://silverblue.fedoraproject.org/
https://kinoite.fedoraproject.org/
https://guix.gnu.org/
https://mobile.nixos.org/
https://repology.org/

Im Februar 2020 wurde schon angekündigt, dass OpenSSH die Unterstützung von ssh-rsa auslaufen lässt. Umgesetzt wurde dies in Version 8.8, die vor gut einem Monat veröffentlicht wurde.

Leider unterstützt nicht jedes System moderne HostKeyAlgorithms. Ein solches Beispiel konnte ich die Tage z. B. bei einem Switch beobachten konnte. Hier erscheint folgender Fehler:

Unable to negotiate with 192.168.1.1 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

In so einem Fall kann man ausnahmsweise doch noch ssh-rsa erlauben und das geht entweder per Option im ssh-Aufruf:

ssh -o HostKeyAlgorithms=+ssh-rsa 192.168.1.1

oder man trägt es in die ~/.ssh/config dauerhaft ein:

Host XYZ
    HostName 192.168.1.1
    HostkeyAlgorithms +ssh-rsa
    PubkeyAcceptedAlgorithms +ssh-rsa

Di, 30. November 2021, Lioh Möller

Die Bedienung eines Computers oder Mobiltelefons überfordert oftmals ältere Menschen. Insbesondere, wenn sie zuvor nie in Kontakt damit gewesen sind. Dennoch möchten sie die Verbindung mit den Enkelkindern aufrechterhalten und Mails schreiben oder eine Recherche im Internet durchführen. Die französische Firma Ordissimo SA, welche bis 2018 unter dem Namen Substantiel geführt wurde, hat sich dem Thema bereits zu Beginn der Nullerjahre angenommen. Ziel war es den ersten Computer für alle Informatik-Anfänger zu entwickeln. Im Jahre 2005 wurde dann das erste Ordissimo-Modell veröffentlicht. Ein auf dem Linux-Betriebssystem basierender Computer mit einer angepassten Benutzeroberfläche. Seither hat sich viel getan und bereits in 2013 konnte das 50'000te Ordissimo-Gerät verkauft werden.

Das Bedienkonzept ist dabei einzigartig gestaltet und ermöglicht einen schnellen Zugriff auf die wichtigsten Funktionen. Als Technologie kommt bis dato ein angepasster Enlightenment Desktop zum Einsatz. Bekannte Applikationen wie Thunderbird, Firefox oder LibreOffice wurden mit einem vereinfachten User-Interface versehen und der eigens entwickelte Dateimanager ermöglicht einen einfachen Zugriff auf Dokumente, Bilder, Datenträger und mehr.

Auch die Druckereinrichtung ist, sofern das Modell unterstützt wird, in wenigen Schritten vollzogen. Die Ordissimo Hardware zeichnet sich darüber hinaus durch eine Tastatur aus, welche keine doppelt belegten Tasten verwendet.

Zwar stand ein Grossteil der zum Einsatz kommenden Software-Komponenten seit jeher unter einer Freien Lizenz zur Verfügung, die Distribution selbst war allerdings nur im Bundle mit einem Ordissimo-Computer erhältlich.

Ein Projekt aus Italien mit dem Namen Debianissimo versucht seit einigen Jahren diese Lücke zu schliessen und stellt eine installierbare Distribution mit allen Ordissimo Komponenten zur Verfügung.

Die Live-Medien starten dabei zunächst in eine Shell und erst mithilfe von startx lässt sich die Desktopumgebung laden.

Dabei ist im Live-Modus nur ein Bruchteil der Software verfügbar und so empfiehlt sich eine Installation, wobei mindestens 64GB Diskspeicher vorausgesetzt wird. Das enthaltene Installationsprogramm steht bisher nur in italienischer Sprache zur Verfügung. Nach dem ersten Start des Installers führt dieser eine Aktualisierung durch und muss daraufhin erneut aufgerufen werden. Während der Installation wird lediglich die Festplatte ausgewählt. Alle zuvor vorhandenen Daten werden dabei gelöscht.

Sobald das System erfolgreich installiert wurde, startet es nach einem Neustart automatisch in die Grafische Oberfläche. Es empfiehlt sich zunächst im Bereich Einstellungen eine Aktualisierung durchzuführen. Dazu ist ein erneuter Neustart notwendig. Ein Grossteil des auf Debian 9 basierenden Betriebssystems wird read-only gemounted, es lässt daher standardmässig nur bedingt Veränderungen zu. Durch einen remount im beschreibbaren Modus, lässt sich dies temporär ändern.

Wie eingangs erwähnt verfügen nahezu alle Applikationen über eine vereinfachte Oberfläche, die eine einfache Nutzung auch für Computer-Einsteiger ermöglicht.

Das Panel am unteren Bildschirmrand bietet einen schnellen Zugriff auf die wichtigsten Funktionen, sowie einige Bedienelemente wie beispielsweise + und - zum Vergrössern des Bildschirminhaltes. Das Pfeilsymbol macht eine zuvor gemachte Änderung rückgängig (Undo).

Die Distribution eignet sich für alle, die das Ordissimo-Betriebssystem auf einem Standard-PC nutzen möchten. Wer eine Investition nicht scheut, findet im Online-Shop des Original-Herstellers eine breite Auswahl an Hardware.

Quelle: https://debianissimo.it
Download: https://debianissimo.it/cdn/isos/debianissimo-sr2018.iso

Open Source Lösungen sind per se gut für den Datenschutz. Irgendwie hat sich diese Gleichsetzung bei vielen festgesetzt. Doch so einfach ist das nicht und vor allem kommt es auf die Umsetzung an.

Die Gleichsetzung alles, was Open Source ist, ist gleichzeitig gut für den Datenschutz, hat sich in den letzten Jahren in der Öffentlichkeit festgesetzt. Dabei ist das gleich auf mehreren Ebenen falsch und entsprechende Behauptungen sollten bei jedem die Alarmglocken läuten lassen.

Open Source bedeutet erst mal nur, dass der Quellcode frei einsehbar ist. Das ist natürlich gut für eine Überprüfung des Datenschutzes, aber jedem sollte einleuchten, dass man die grauenvollste Software grundsätzlich auch Open Source stellen könnte (ich hatte das am Beispiel Linux auch mal durch dekliniert) Zweitens kommt es beim Datenschutz fast immer auf die konkrete Implementierung an und hier sind nicht umsonst aufwendige Prüfverfahren vorgesehen. Wenn irgendjemand in einer Diskussion pauschal behauptet, Lösung XYZ wäre gut für den Datenschutz, ohne auf die konkreten Details einzugehen, sollte bei jedem die Warnglocken läuten, denn entweder verkürzt derjenige stark oder er hat schlicht keine Ahnung.

Warum das so ist, möchte ich an einem kleinen Beispiel ausführen: Big Blue Button (im folgenden BBB) vs. Zoom.

Big Blue Button ist der Darling der Open Source Szene in Pandemie-Zeiten. Eine leistungsstarke Videokonferenzlösung, die quelloffen ist und transparent auf GitHub entwickelt wird. Zoom hingegen war schon vor der Corona-Pandemie suspekt und spätestens seit dem Frühjahr 2020 Gegenstand heißer Auseinandersetzungen. Also eigentlich klar, was hier hinsichtlich Datenschutz die Nase vorn hat, oder?

Das folgende Gedankenexperiment soll zeigen, dass so etwas eben nicht so klar und eindeutig ist, wie das gerne dargestellt wird.

Beide Videokonferenzsysteme arbeiten nicht per P2P-Prinzip, sondern benötigen eine zentrale Infrastruktur. Bei BBB wird meist davon ausgegangen, dass diese durch die nutzende Einrichtung betrieben wird, man kann dafür aber natürlich auch auf Dienstleister zurückgreifen. Zoom wird hingegen in der Regel durch die Zoom Inc. gehostet, es gibt aber auch die Möglichkeit, für große Einrichtungen die Zoom-Server selbst in ihren Rechenzentren zu betreiben.

Beide Systemen haben zudem positive wie negative Funktionen. Nur ein paar Beispiele zum Verständnis: Zoom bietet neben vielen kritisieren Funktionen auch eine Inhalteverschlüsselung für Videokonferenzen und hat dieses Thema erst richtig auf die Agenda gesetzt. BBB wird zwar transparent entwickelt, hat aber in der Vergangenheit Probleme mit der Sicherheit gehabt und die Umsetzung der für den Anwender nicht ersichtlichen Aufzeichnung aller Sessions ist höchst problematisch und muss durch den Administrator ggf. komplett deaktiviert werden.

Spannend wir nun also mal ein denkbar ungünstiges Szenario für BBB auf:

Die Einrichtung hat nicht die notwendigen Kapazitäten oder Expertise BBB selbst zu betreiben. Eine große Instanz für bis zu 300 gleichzeitige Teilnehmer ist schließlich nicht ganz trivial zu betreiben. Stattdessen nimmt man einen Dienstleister. Wenn man jetzt ein richtig negatives Szenario haben möchte, dann sitzt dieser Dienstleister noch nicht mal in der Europäischen Union, aber es funktioniert auch mit einem Sitz in der EU. Weil es schnell gehen musste, ist die vertragliche Basis lückenhaft und der Auftragsdatenverarbeitungsvertrag existiert nicht. Welche BBB-Version genau beim Dienstleister läuft ist unklar, theoretisch könnte es sich sogar um eine von der frei verfügbaren Open Source-Lösung abgewandelte Variante handeln. Ob der Dienstleister die problematischen Funktionen bei BBB deaktiviert hat, kann nicht kontrolliert werden. Ein besonderer Fokus auf Datensparsamkeit bei der BBB-Instanz existiert nicht. Weil BBB nur eine Transport- und keine Inhalteverschlüsselung bietet, sind für den Dienstleister potenziell alle Inhalte und Metadaten frei verfügbar.

Nehmen wir nun das denkbar günstigste Szenario für Zoom zum Vergleich. Die Einrichtung hat nicht nur eine teure Lizenz, sondern betreibt die Zoom-Server sogar in den eigenen Rechenzentren (Zoom on-premise). Die Metadaten, d. h. vor allem welche Benutzer eingeladen sind und wann das Meeting stattfindet, landet zwar weiterhin bei Zoom, der gesamte Meeting-Verkehr wird aber über die eigene Infrastruktur abgewickelt. Durch die Inhalteverschlüsselung ist das zudem deutlich sicherer als bei nahezu allen konkurrierenden Lösungen. Versteckte Aufzeichnungen etc. pp. gibt es bei Zoom nicht, hier hat man in den vergangenen Jahren durch den ständigen Fokus der Öffentlichkeit viel nachgearbeitet.

Welche Lösung ist nun hinsichtlich des Datenschutzes die bessere?

Natürlich hat dieses Szenario in sofern Schlagseite, als dass ich das denkbar ungünstigste BBB-Szenario dem denkbar günstigsten Zoom-Szenario gegenüber gestellt habe und das somit eine eher theoretische Fingerübung ist.

In der Realität würde man als lokaler Datenschutzbeauftragter darauf drängen, eine saubere BBB-Infrastruktur zu betreiben und Verbesserungen in dem Bereich vornehmen, weil das Entwicklungspotenzial hier besser ist als bei Zoom, wo man letztlich um den problematischen Metadatenabfluss an Zoom nicht umhin kommt.

Daraus lernen kann man aber, dass die Aussage, ob etwas gut oder schlecht für den Datenschutz ist, bei nahezu allen komplexeren Fällen wie z. B. einer Videokonferenzinfrastruktur niemals pauschal gesagt werden kann, sondern immer das Ergebnis einer intensiven Prüfung unter Einbeziehung aller Faktoren ist. Hinzu kommt oft eine gewisse Freiheit bei der Risikoabwägung, weshalb ähnlich wie bei Juristen gilt: 3 Datenschützer, 5 Meinungen. Jeder, der mal beruflich im Datenschutz gearbeitet hat, weiß das.

Wenn ihr also Pauschalurteile zum Datenschutz lest, dann wisst ihr entweder, dass derjenige stark verkürzt, seine Meinung schon vorher feststand oder der Autor schlicht keine Ahnung von Datenschutz im wirklichen Arbeitsalltag hat – denn da gibt es selten eindeutige oder perfekte Lösungen.

Der Artikel Open Source = Datenschutz? So einfach ist das nicht! erschien zuerst auf [Mer]Curius

Wie Benjamin Brunner, Entwickler bei SUSE, vor einigen Tagen über die Mailingliste kommunizierte, arbeitet man momentan an der Implementierung der neuen systemd-Funktionen, um LUKS2-Volumes mittels TPM oder FIDO2 zu entsperren.

Dabei handelt es sich um eine Funktion, die Lennart Poettering Anfang diesen Jahres ankündigte und über die ich hier bereits berichtete hatte. Mittels systemd-cryptenroll lassen sich unter anderem TPM oder FIDO2 als Entsperrmechanismen für LUKS2 hinterlegen. Diese neuen Verfahren stehen in einem direkten Kontext zu weiteren Bestrebungen, um den Sicherheitslevel der verbreiteten Linux-Verschlüsselung auf ein zeitgemäßes Niveau zu bringen.

Die Zielrichtung der Bestrebungen bei SUSE/openSUSE ist noch nicht klar. Also ob und inwieweit das in die Installationsroutine oder YaST implementiert wird. Zudem sind noch einige Vorarbeiten notwendig. Genaueres können interessierte Anwender im Wiki nachlesen.

Die Funktion systemd-cryptentroll benötigt LUKS2-Volumes. Das ist für SUSE/openSUSE ein Problem, weil die Installationsroutine bis zuletzt LUKS1-Volumes angelegt hat. Daran hat man allerdings anderweitig bereits gearbeitet und ich denke, hier dürfte sich zukünftig was ändern. Bestehende Installationen lassen sich zudem relativ leicht mittels eines Live-Mediums von LUKS1 auf LUKS2 migrieren. Allerdings benötigt systemd-cryptenroll auch eine unverschlüsselte Boot-Partition und das ist standardmäßig bei SUSE/openSUSE schon länger nicht mehr der Fall.

Hinzu kommen noch ein paar Probleme, weil z. B. die FIDO2-Abfrage upstream noch nicht in Plymouth integriert ist und somit nicht optisch schön beim Startvorgang erscheint, sondern „blind“ durch den Anwender erfolgen muss.

Die beiden neuen Authentifizierungsmethoden sind wichtige Ergänzungen für die Legacy-Verfahren mittels Passwort. Teilweise lösen sie auch zusammen gestückelte Skripte bei z. B. Debian und Arch Linux ab, die bereits Sicherheitssticks wie den YubiKey unterstützten. FIDO2 adressiert das Problem der unsicheren Passwörter und TPM2 bietet unter anderem Schutz gegen Angriffe mittels Brute Force und vor allem das beliebte Kopieren der Daten, um sie danach in aller Ruhe zu untersuchen.

Es ist also noch ein wenig Wegstrecke zu meisten, bis diese Funktionen standardmäßig umgesetzt werden können. Wer aber schon ein System mit LUKS2 und unverschlüsselter Boot-Partition hat oder eine Testinstallation betreibt, kann sich die neuen Funktionen mal ansehen. Meiner Meinung nach geht das absolut in die richtige Richtung.

Der Artikel openSUSE arbeitet an LUKS mit TPM und FIDO2 erschien zuerst auf [Mer]Curius

Traditionell gebe ich gegen Ende des Jahres einen kleinen Einblick in mein Nutzungsverhalten und das, was sich im vergangenen Jahr geändert hat. Viele Verfechter von Datenschutz und Privatsphäre schreiben gerne über das richtige Nutzungsverhalten, aber jeder muss Kompromisse machen.

Der Blog auf [Mer]Curius spiegelt meine gegenwärtigen Interessen im Bereich Datenschutz/-sicherheit meist ziemlich gut wider. Für viele Leser dürften sich daher einiges Bekanntes wieder finden.

Hardware & Betriebssysteme

Meine Rückkehr zu Linux hat sich im letzten Jahresrückblick bereits abgezeichnet. Es hat dann doch stärker geruckelt, als ich das anfänglich vermutet hatte. Einfach, weil ich mir in den Apple-Jahren einen gewissen Komfort angewöhnt habe, den ich nicht mehr missen möchte. Ein weiterer für mich wichtiger Aspekt ist Datenschutz und Sicherheit. Linux ist hier nicht so optimal aufgestellt, wie es gerne dargestellt wird. Hier tut sich zum Glück einiges und mittelfristig dürfte Linux hier deutlich besser dastehen. Leider sehen das nicht alle so und so treibt mich die selbstzufriedene Bräsigkeit großer Teile der Community regelmäßig auf die Palme. Zum Leidwesen mancher Leser.

Meine anfängliche Unzufriedenheit konnte ich zumindest teilweise lösen, indem ich von KDE Plasma zur Pantheon Shell migriert bin. Bei der Rückkehr zu Linux hatte ich die Wahl von Plasma als Desktop kaum hinterfragt, schließlich steigt man meist wieder da ein, wo man vorher aufgehört hat, aber nach langen Jahren mit macOS habe ich das Stückwerk ohne erkennbare Leitlinie der VDG einfach nicht mehr ertragen.

Grundsätzlich habe ich die partielle Abkehr von macOS aber nicht bereut. Auch ein Jahr nach der Veröffentlichung der ersten Geräte mit M1 Prozessor kann man kein anderes Betriebssystem auf den Geräten nutzen und Virtualisierung funktioniert nur sehr eingeschränkt mit ARM-VMs. Zudem experimentiert Apple mit zweifelhaften Funktionen wie Client Side Scanning und sollten die zur Marktreife kommen, steht der Kunde mangels alternativer lauffähiger Betriebssysteme mit einem Haufen Elektroschrott da. Jedenfalls sofern das Themen sind, die den Nutzer umtreiben – so wie mich eben. Linux bietet hier mehr Freiheit, wenn sich ein Projekt in die falsche Richtung entwickelt. Man ist nicht derart auf Gedeih und Verderb einem einzigen Hersteller oder Entwicklerteam ausgeliefert.

Wobei das nicht bedeutet, dass ich niemandem zu Apples Hardware raten würde. Vergangene Woche haben wir hier im Haushalt ein MacBook Air 2020 angeschafft. Schönes und extrem flottes Gerät und wunderbar geeignet, wenn der Anwender damit einfach in Ruhe seine Sachen erledigen möchte. Nur für mich eben als Hauptgerät nicht mehr geeignet.

Mobil habe ich vergangenes Jahr verstärkt mit LineageOS gearbeitet und bereite gerade den Umstieg auf GrapheneOS mit neuer Hardware vor. Alternativ gibt es noch ein iPhone SE 2020, das sicher noch viele Jahre als Alltagsgerät seinen Dienst tun wird.

Kern meiner Datenhaltung und Synchronisation ist immer noch das gleiche Synology NAS wie seit Jahren. Ich bin dabei mit Synology nicht übermäßig glücklich, weil ich die Updatepolitik hinsichtlich Sicherheitsupdates bei einem so exponierten System nicht professionell genug finde, aber so lange die Hardware läuft und unterstützt wird, werde ich hier wohl nicht migrieren.

Homeoffice im zweiten Jahr

Während privat Open Source nun wieder viel stärker zum Einsatz kommt, bin ich beruflich so richtig schön proprietär unterwegs und finde das nicht mal schlecht. Ich könnte wegen der aktuellen Sonderregelungen (Corona, Homeoffice etc. pp.) sogar mit Linux arbeiten, aber möchte es gar nicht. Aufgrund ausgedehnter Homeoffice-Zeiten gehören diese Betriebssysteme und Programme inzwischen auch faktisch in meinen IT-Haushalt und werden daher hier aufgeführt.

Windows, Microsoft Office, Citavi, Zoom, das ein oder andere Microsoft Teams oder WebEx-Meeting. Ja, hartleibigen Datenschützern dreht sich hier der Magen um, aber es funktioniert und leider auch viel besser als Lösungen wie Big Blue Button, das wir auch haben und wo die Ärgernisse von der eher bescheiden Oberfläche, den bescheidenen Funktionen und der noch bescheideneren Performance inzwischen zum üblichen Smalltalk der Videocalls gehören. Endlich eine Alternative zum Wetter und Pandemie-Status.

Kommunikation

Abgesehen von der Arbeitskommunikation hat es in diesem Bereich im letzten Jahr erstaunliche Fortschritte gegeben.

Die E-Mail ist bei mir massiv auf dem Rückzug. Da ich E-Mails nie lösche und lediglich in Jahresarchive absortiere kann ich das auch gut quantifizieren. Dieses Jahr habe ich knapp 50 % weniger Mails bekommen und beantwortet als im Vorjahr, womit sich ein langjähriger Trend noch mal beschleunigt hat.

Stattdessen hat aufgrund der amateurhaften Kommunikationspolitik von Facebook Signal bei mir dieses Jahr einen Quantensprung gemacht. 70 % meiner Kontakte und Gruppen kann ich inzwischen über Signal abwickeln. Die Migrationsbewegung hielt aber nur kurz an und seit dem Sommer hat sich hier nichts mehr getan. Die verbliebenen WhatsApp-Kontakte sind echt renitent, weshalb mir WhatsApp erhalten bleibt. Wirklich verloren hat Threema, das bei mir fast keine Rolle mehr spielt. Wenn die Handvoll Kontakte dort noch auf Signal migriert, brauche ich es eigentlich nicht mehr.

Dienste

Ähnlich wie letztes Jahr ist dieser Bereich bei mir sehr statisch. Gerade noch einen Blick auf Desktop und Smartphone geworfen. Das meiste wie z. B. den PIM-Bereich, „Cloudspeicher“ oder RSS-Synchronisation betreibe ich selbst. Der Eigenbetrieb gewährleistet bei mir die höchstmögliche Sicherheit bei gleichzeitigem maximalen Komfort, weil ich eben doch alle Vorteile nutzen kann, die sich aus „Clouddiensten“ und Synchronisation ergeben.

Bei der Suchmaschine nutze ich immer noch DuckDuckGo. Vermutlich nicht die beste Lösung hinsichtlich des Datenschutzes, aber für mich die beste Kombination aus Ergebnisqualität und Datenschutz. Eine Suchmaschine mit der ich nichts oder nur mangelhafte Ergebnisse erziele, nützt mir schließlich auch nichts. Am Desktop arbeite ich für die Navigation sehr zufrieden mit GNOME Maps, für Android nutze ich OsmAnd, wobei ich damit nicht sonderlich zufrieden bin, weil die Oberfläche überladen und die Suchfunktion unterirdisch ist.

Sünden

Nicht nur die genutzten Dienste ändern sich kaum, sondern auch der Katalog an „problematischen“ Diensten und Lösungen ist ziemlich statisch. Twitter, WhatsApp und als besonderes Ärgernis der DB Navigator bleiben mir als besonders problematische Dienste erhalten. Perspektivisch hoffe ich hier wenigstens auf WhatsApp verzichten zu können. Zudem habe ich immer noch zwei Streaming-Dienste für Serien und die DSGVO-Auskunft bei beiden hat es in sich.

Bei der Hardware meide ich den Smart Home-Trend, habe aber inzwischen einen TV von LG mit webOS Betriebssystem (was so gut wie nichts mehr mit den Palm-Wurzeln zu tun hat), von dem ich lieber nicht so genau wissen möchte, was er so an Daten sendet und Sonos Speaker, bei denen das Gleiche gilt.

Der Artikel Wasser predigen, Wein trinken? – Mein Nutzungsverhalten 2021 erschien zuerst auf [Mer]Curius

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

Dieser dritte Teil der NixOS-Artikelserie befasst sich mit einigen und doch längst nicht allen der grossen und kleinen Tricks, die der Paketmanager Nix im Ärmel hat.

Kurz vorab: was er im Gegensatz zu den meisten anderen Paketmanagern wie apt, pacman, dnf und Flatpak leider nicht bietet, ist die Integration in GUI-Softwaremanager wie Gnome Software. Doch wer sich bereits durch die Installation und Konfiguration von NixOS gearbeitet hat, den wird das vermutlich nicht abschrecken.

Systemkonfiguration

Der auf NixOS wichtigste Weg, um Software zu installieren oder zu entfernen ist, sie in der Systemkonfiguration /etc/nixos/configuration.nix zu deklarieren. Viele Optionen, die hier gesetzt werden können, implizieren bereits die Installation der benötigten Software. Darüber hinaus können in environment.systemPackages = [ ... ] weitere gewünschte Softwarepakete gelistet werden.

Updates

NixOS wird beim Ausführen des Befehls sudo nixos-rebuild switch --upgrade nicht nur, wie aus Teil 2 bekannt, die Konfiguration neu anwenden, sondern auch alle Software auf den neuesten Stand aktualisieren.

Anstatt dies immer wieder neu auszuführen, kann auch ein automatischer Dienst dafür in der Konfigurationsdatei aktiviert werden, mit der Zeile:

system.autoUpgrade.enable = true;

nix-shell

Nix ermöglicht es, mit dem Befehl nix-shell eine Shell zu starten, in der bestimmte gewünschte Software ohne Installation zum Ausprobieren zur Verfügung steht. nix-shell -p htop öffnet diese Shell beispielsweise mit htop als zusätzlich verfügbarem Befehl. nix-shell startet in diesem Beispiel htop, ohne es systemweit oder auch nur, wie im Folgenden beschrieben, im Benutzer-Kontext verfügbar zu machen.

Auf -p dürfen auch mehrere Paketnamen folgen. Die zwei Befehle lassen sich auch zu einem verbinden: nix-shell -p htop --run htop.

nix-env

NixOS erlaubt auch das dauerhafte Installieren von Software, ohne sie in die Systemkonfiguration einzutragen. Allerdings sollte man sich gut überlegen, ob man das tun möchte, denn nix-env ist ein einzelner Befehl, der Zustand ändert, und widerspricht somit dem deklarativen Ansatz.

Bei nix-env wird nur das jeweilige Profil geändert, das bedeutet, dass nur der jeweilige Nutzer beeinflusst ist. nix-env -iA nixos.htop installiert htop somit nur für den einzelnen Nutzer. Installieren zwei Nutzer dasselbe Paket, wird es nicht den doppelten Speicherplatz benötigen, sondern derselbe Nix-Store-Eintrag einfach beiden Nutzern zur Verfügung gestellt.

Weitere Optionen sind -u '*' für Updates in dem Profil, -e htop zum deinstallieren, sowie --rollback. Führt man nix-env mit sudo bzw. mit dem Rootaccount durch, wird das Systemprofil bearbeitet. Dessen Pakete stehen allen Nutzern zur Verfügung.

nix-collect-garbage

Der Nix-Store behält alle Softwareversionen, Systemgenerationen, Profile und per nix-shell genutzte Software im Hintergrund. Mit nix-collect-garbage lässt sich ein wenig aufräumen: alles, was von keinem Profil und keiner Systemgeneration mehr gebraucht wird, wird gelöscht.

Wichtiger ist die Variante nix-collect-garbage -d. Hier werden vor dem Löschen alle Systemgenerationen bis auf die aktuelle aus den Bootoptionen entfernt. Dabei ist zu bedenken, dass man anschliessend nicht mehr zurückrollen kann. Nun resultiert das Löschen in potenziell sehr viel mehr frei werdenden Speicherplatz, weil die alten Generationen alle nicht mehr behalten werden müssen.

Beides lässt sich automatisieren. Beispielsweise wird mit der folgenden Konfiguration täglich gelöscht, was seit 30 Tagen von keiner Konfiguration genutzt wurde:

nix.gc = {
    automatic = true;
    dates = "daily";
    options = "--delete-older-than 30d";
};

Und die folgende Option (hier bei einer UEFI-Installation) limitiert die Bootoptionen auf die neuesten 10:

boot.loader.systemd-boot.configurationLimit = 10;

Ältere Generationen werden aus den Bootoptionen entfernt, und die entsprechenden Nix-Store-Inhalte können vom Garbagecollector gelöscht werden.

Optimierung

Der sehr zeitintensive Befehl nix-store --optimize dedupliziert den Nix-Store auf Dateiebene, was in einigen Fällen ebenfalls beträchtliche Speicherplatzeinsparung bedeuten kann. Auch er kann als Hintergrunddienst eingerichtet werden, mit der Konfigurationsoption

nix.optimise.automatic = true;

Links

https://nixos.org
https://nixos.org/manual/nixos/stable/
https://nixos.org/manual/nix/stable/
https://nixos.wiki
https://search.nixos.org

Fr, 26. November 2021, Caos

Als es im letzten Jahr unerwartet ins Homeoffice oder ins Homeschooling ging, brauchten in meinem Umfeld viele plötzlich einen (weiteren) Laptop. Zum Teil waren noch ältere Geräte vorhanden, die wiederbelebt werden konnten. Diese stammten teilweise noch aus der Windows-XP-Ära und unterstützten kein 64-Bit. Aus diesem Anlass habe ich etwas ausführlicher recherchiert, welche Distributionen noch für ältere Geräte einsetzbar sind, habe einiges ausprobiert und einige alte Geräte konnten so zu neuem Leben erweckt werden.

Linke Spalte v. oben n. unten: Bunsenlabs, Raspberry Pi OS Desktop, Sparky; Mitte v.o.n.u.: LMDE, Q4OS, MX; Rechts v.o.n.u.: Bodhi, Slitaz (Bildquelle: eigene Screenshots)

Die meisten grossen Linux-Distributionen haben im Laufe der letzten Jahre die Unterstützung für 32-Bit eingestellt. Vor allem seit Ubuntu mit Version 19 keine 32-Bit Hardware mehr unterstützt, sind nicht nur auch die leichtgewichtigeren Ubuntu-Flavours wie Lubuntu und Xubuntu nur noch als 64-Bit-Variante verfügbar. Der Support für die 18.04 LTS-Versionen der Flavours endete bereits im April 2021. Auch andere auf Ubuntu basierende Distributionen bieten infolgedessen keine aktuelle 32-Bit-Version mehr an. So etwa auch die aktuellste Puppy-Version (FossaPub), obwohl Puppy explizit auf ältere Hardware abzielt und extrem ressourcenschonend läuft. Einige „Puppies“, die auf älteren Ubuntu-Versionen aufsetzen, bieten aber noch 32-Bit-Varienten an und eignen sich besonders als Live-System. Ubuntu-Abkömmlinge wie Linux Lite und das aktuelle Linux Mint 20 laufen dagegen nur noch auf 64-Bit-Geräten.

Doch nicht verzagen! Ein bisschen Auswahl besteht noch und es gibt immer noch einige 32-Bit-Distributionen, die aktuell gepflegt werden und auch für einen Produktivbetrieb einsetzbar sind.

Dies sind zum Grossteil Distributionen wie Debian selbst und solche, die auf Debian basieren. Allen voran die Linux Mint-Variante LMDE4 (Linux Mint Debian Edition). Die offizielle Version gibt es mit Cinnamon-Desktop, aber die Mint-Community bietet auch fertige ISOs mit leichtgewichtigeren Desktops wie LXDE an. Für Zorin OS 16 ist die Lite-Version bislang nur im Zorin-Forum angekündigt. MX-Linux ist mit XFCE und mit Fluxbox-Desktop (nicht jedoch mit KDE) als 32-Bit-Version verfügbar. LMDE, Zorin Lite und MX sind mittelschwere Distributionen, die auf Geräten mit 3-4 GB Arbeitsspeicher noch sehr komfortabel nutzbar sind. Die Mindestanforderung ist 1 GB RAM, bei 2 GB oder weniger sind aber möglicherweise noch schlankere Distributionen von Vorteil:

• Sparky-Linux basiert auf Debian „Buster“ und bietet 32-Bit-Abbilder mit LXQt, Xfce sowie MinimalGUI und MinimalCLI. Die minimalen Systemanforderungen variieren dementsprechend zwischen 128 MB (CLI) und 512 MB (Xfce).

• Bunsenlabs ist aus CrunchBang-Linux hervorgegangen und bietet einen flotten Window-Manager (modifiziertes Openbox) und eine besondere und minimalistische Ästhetik.

• Slitaz verwendet ebenfalls Openbox als Window-Manager und eignet sich eher als Bunsenlabs auch für unerfahrenere Anwender:innen.

• Elive mit Enlightment-Desktop beschreibt sich selbst als „Fast, Beautiful and Powerful OS“. Die Schnelligkeit ist relativ unbestritten und die Schönheit können sicher nicht alle, aber bestimmt einige darin erkennen.

• Eine gute und ebenfalls anwenderfreundliche Alternative insbesondere für Netbooks ist auch Raspberry Pi OS Desktop (ehemals Raspbian).

Distributionen, die besonders ressourcenschonend sind und auch mit äusserst geringer RAM-Kapazität schnell laufen, sind Bodhi Linux und Antix. Bodhi Linux ist enorm schnell, aber hat mit dem Desktop-Unikat „Moksha“ eine eher gewöhnungsbedürftige Optik und ist umständlich in der Benutzerführung. Die aktuellste 32-Bit Version ist angekündigt als "cooming soon". Antix bietet eine Fülle von schlanker Software und eignet sich sehr gut als Livesystem, unter anderem die Menüführung ist jedoch etwas verwirrend und überladen. Sowohl Bodhi als auch Antix verbrauchen im Leerlauf aber nur ca. 100 MB RAM.

Wer es etwas konventioneller mag, sollte sich einmal Q4OS ansehen: Q4OS ist nicht nur für Windows-Nostalgiker geeignet, sondern eine wirklich solide und benutzerfreundliche Distribution, die mit Trinity-Desktop auch bei geringen RAM-Ressorcen sehr schnell läuft. Auch hier ist der initiale RAM-Bedarf nur ca. 100-150 MB.

Wenn die Möglichkeit besteht, kann vielleicht auch die Hardware noch mit RAM nachgerüstet werden. Dies ist jedoch nicht immer realisierbar: Entweder, weil passende RAM-Riegel gar nicht mehr oder nicht zu angemessenen Preisen erhältlich sind oder weil das Gerät nur bis maximal 2 GB aufrüstbar ist, was bspw. auf viele Netbooks oder ältere Thinkpads wie das T42 zutrifft.

Ein weiterer Faktor bei geringen RAM-Ressourcen ist der Einsatz von ressourcenschonenden Software-Alternativen: Wenn bspw. der Funktionsumfang der LibreOffice-Suite überdimensioniert ist, kommen Abiword als Writer- und Gnumeric als Calc-Alternative infrage. Auch Firefox schraubt leider den Arbeitspeicher-Gebrauch erheblich in die Höhe. Als Browser-Alternative ist hier u.a. Palemoon einen Versuch wert. Palemoon ist ein Fork einer älteren Firefox-ESR-Version, der zwar ein weniger modernes Design bietet, aber merklich schneller läuft. Auch wichtige Addons wie Ublock Origin sind damit nutzbar.

Etwas schwieriger gestaltet sich die Distributions-Suche für Geräte, deren Prozessor die Erweiterung PAE (Physical Adress Extension) nicht unterstützt. Zum Teil kann das durch Ergänzung des Bootparameters „forcepae“ erzwungen werden, was jedoch oft nicht zum Erfolg führt. Von den genannten Distributionen laufen LMDE, Bunsenlabs, Sparky, Antix und Bodhi auch ohne PAE bzw. bieten spezielle Abbilder für diesen Zweck an.

Weitere aktuelle Linux-Distributionen, die noch 32-Bit-Varianten anbieten, sind unter anderem: Emmabuntüs, Escuelas, Devuan, Fluxuan und Miyo (alle mit Debian-Basis). Hinzu kommen einige Distributionen, die nicht direkt oder indirekt auf Debian aufbauen wie Mageia, Artix oder VOID.

Fazit

Es gibt also auch im Jahre 2021 noch vielfältige Möglichkeiten, alte PCs oder Laptops mit 32-Bit-CPUs weiterzubetreiben oder zu reaktivieren. In noch folgenden Artikeln werde ich einige der genannten Distributionen noch etwas genauer vorstellen.

Do, 25. November 2021, Niklas

Am 31. Januar 2021 wurde ein neues Betriebssystem-Projekt gestartet. Helium, so hiess airyxOS am Anfang, sollte ein freier Nachbau von Apples proprietärem macOS werden, der viel weiter geht, als die vielen Open-Source Docks oder Themes für KDE und GNOME. Es soll tatsächlich auch original macOS Programme ausführen können, während die Unterstützung für FreeBSD Programme beibehalten wird. Linux Programme sollen über FreeBSDs Linux-Kompatibilitätsschicht ebenfalls unterstützt werden.

Damit geht das Projekt mehr in die Richtung dessen, was ReactOS für Windows ist - allerdings ohne komplett eigenen Kernel, was die Entwicklungszeit von airyxOS hoffentlich beschleunigen dürfte. Stattdessen will das Projekt auf FreeBSD aufbauen. Da Apple selbst Teile von FreeBSD für seinen Darwin Kernel verwendet, dürfte eine Kompatibilitätsschicht hier einfacher machbar sein, als beispielsweise mit Linux.

Erst vor wenigen Tagen hat airyxOS mit Version 0.3.0 "Tanuki" seine erste Beta-Version veröffentlicht. Ich habe sie ausprobiert und bin angesichts des sehr frühen Entwicklungsstadiums noch nicht voll überzeugt, aber ich denke, das Projekt hat Potenzial. Die durchaus gelungene Erfahrung mit der Bedienoberfläche wird überschattet von diversen Bugs und Treiberproblemen.

Der Desktop von airyxOS basiert auf KDE Plasma, aber das ist kaum noch zu erkennen. Das komplette Design wurde macOS nachempfunden. Einzig die KDE-typischen Systemeinstellungen und einige der Pop-ups, die beim Klick auf Tray Icons erscheinen, verraten noch, welche Software hier läuft. Alles in allem wirkt das sehr stimmig und durchdacht.

Mit dem Dock fehlt allerdings noch eine wichtige Komponente des macOS UI. Es ist so nicht ganz einfach, Programme zu starten. Es gibt nur einen Applications Ordner im Filer, von dem aus man Programme starten kann. Um geöffnete, minimierte Programme wieder hervorzuholen, gibt es ein Hot Corner in der oberen linken Ecke.

Der Filer ist der Dateimanager von airyxOS. Er wurde vom helloSystem Projekt geforkt, das wir bereits vorgestellt haben. Die beiden Systeme haben bezüglich ihrer Bedienoberfläche ja sehr ähnliche Ziele, auch wenn sie zum Teil sehr unterschiedlich umgesetzt wurden. Der erste Eindruck ist gut, ein sehr simples Programm, in dem man sich schnell zurechtfindet. Nur ein schwerwiegender Bug ist mir hier aufgefallen: Wenn man im Root Verzeichnis auf Get Info klickt, stürzt das komplette System ab und startet neu. In anderen Ordnern funktioniert das korrekt.

Die Auswahl an vorinstallierten Programmen ist noch eher klein. Hier finden sich nur Kate als Texteditor und Firefox als Browser. Mit diesen beiden hat man auf jeden Fall eine gute Wahl getroffen. Der Firefox bringt bei mir leider nach ein paar Sekunden das ganze System zum Hängen, nur ein Neustart hilft. Ich gehe aber davon aus, dass das noch behoben wird.

Bis jetzt handelt es sich bei der vorinstallierten Software komplett um native FreeBSD Programme, wie sie auch im FreeBSD Repository verfügbar wären (allerdings teilweise ins airyxOS-eigene .app Format verpackt). airyxOS soll auch quelloffene Cocoa Programme, also native macOS Programme ausführen können, wenn man diese auf airyxOS neu kompiliert. Zu gerne hätte ich das ausprobiert, aber das scheitert am nicht funktionierenden Internet, wodurch ich mir keine Repositorys zum Testen clonen kann.

Zu einem späteren Zeitpunkt will airyxOS auch Binärpakete von macOS ausführen können, wodurch auch proprietäre Software genutzt werden kann. Ob das langfristig funktionieren kann, ist fraglich, nachdem Apple auf die ARM Architektur gewechselt hat und airyxOS weiterhin auf x86_64 setzt. Solange noch Software für Intel Macs erscheint, sollte es aber machbar sein.

Ich halte airyxOS für ein höchst interessantes Projekt, das nach nicht mal einem Jahr Entwicklungszeit schon etwas auf die Beine gestellt hat, was man fast als nutzbar bezeichnen könnte. Die Version wird zwar Beta genannt, fühlt sich aber eher nach pre-Alpha an. Wenn wir airyxOS noch ein oder zwei Jahre Zeit geben, kann ich mir gut vorstellen, dass hier etwas entstehen wird, was sich insbesondere für weniger technisch versierte Nutzer gut im Alltagsgebrauch eignet.

Zur Hardwareunterstützung: Hier wird FreeBSD 12.3 eingesetzt, also sollte airyxOS mit jedem Gerät funktionieren, das auch mit FreeBSD 12.3 funktioniert. In der Praxis sieht das nicht ganz so aus, aber es kann als Anhaltspunkt dienen. Auf meinem Testlaptop, ein Lenovo 3000 N200, mit dem ich bereits einige Systeme auf FreeBSD 12 Basis erfolgreich getestet habe, will airyxOS gar nicht. Einmal bootet es in einen schwarzen Bildschirm mit Mauszeiger, beim zweiten Versuch in einen schwarzen Bildschirm ohne Mauszeiger. Ich habe dann aufgegeben.

Auf meinem Computer, ein HP Compaq aus dem Jahre 2009, bekomme ich kein Internet (weder WLAN-Stick noch Handy mit Tethering werden erkannt) und die Bildschirmauflösung ist zu gering. Mit dem neueren FreeBSD 13, das ich auf diesem Gerät normalerweise nutze, funktioniert Internet, aber die Bildschirmauflösung... ist halt einfach Nvidia... Hier konnte ich die Tests mit gewissen Einschränkungen (keine Downloads, keine Programme installieren, keine Repositorys clonen, ...) durchführen.

Natürlich behalte ich die Entwicklung von airyxOS im Blick und werde berichten, was sich mit der nächsten Version verändert und was jetzt funktioniert, womit ich heute noch Probleme hatte. Über Kommentare mit eigenen Testberichten würde ich mich freuen, vielleicht kommt der eine oder andere ja schon weiter mit dem System.

Quellen:

• https://airyx.org
• https://github.com/mszoek/airyx
• https://github.com/mszoek/airyx/releases
• https://github.com/mszoek/airyx/tree/d4895aba2d59b17368bf5d285ee03cc2f4a6e719