Fabian Schaar

…im Internet.

Schlagwort: Container

  • GNU/Linux: Zettlr-Flatpak und das Dateisystem

    Einsortiert in:

    Neulich gab es im Zettlr-Subreddit einen Problembericht, in dem ein Nutzer beschrieb, dass sein Zettlr-Flatpak unter GNU/Linux nicht auf das gesamte Heimverzeichnis zugreifen konnte. Stattdessen werde nur der Ordner für Dokumente erkannt bzw. angezeigt. Der Fragesteller hat sich schließlich damit beholfen, an Stelle des Flatpaks einfach ein traditionelles Paket zu installieren. Das muss aber nicht sein, eigentlich ist das „Problem“ schneller gelöst, als man es vielleicht vermuten würde.

    Flatpaks bieten als Container-Technologie die Möglichkeit, die Rechte, die Anwendungen auf dem Host-System haben, einschränken zu können. Das schließt einige Systemdienste ein, betrifft aber auch das Dateisystem. Diese besagten Rechte lassen sich mit einer weiteren Flatpak-Anwendung namens „Flatseal“ verwalten. Diese ist im Flathub verfügbar, kann also ganz einfach über grafische Werkzeuge wie Gnome Software oder die Shell installiert werden:

    flatpak install flathub com.github.tchx84.Flatseal

    Wer möchte, kann die Anwendung auch nur für den jeweiligen Benutzer installieren. Das bietet sich zum Beispiel unter openSUSE MicroOS Desktop an:

    flatpak install --user flathub com.github.tchx84.Flatseal

    Ist Flatseal einmal installiert, kann man in der Anwendungsliste einfach zur jeweiligen Anwendung, in diesem Fall also Zettlr navigieren. Dort findet sich dann in der deutschen Lokalisierung die Sektion „Filesystem“. Dort muss dann lediglich die Option „Alle Benutzerdateien“ aktiviert werden. Dadurch wird die Variable filesystem=home gesetzt und Zettlr kann (nach einem Neustart der Anwendung) auf das gesamte Heimverzeichnis zugreifen.

    Im Allgemeinen sollte man im Hinterkopf behalten, dass die Rechteverwaltung bei Flatpak sicherheitstechnische Gründe hat. Das jeweilige Risiko einzuschätzen, liegt also an der Nutzerin selbst. Übrigens wird so auch klar, warum sich der Fragesteller auf Reddit mit dem traditionellen Paket behelfen konnte: Traditionelle Paketmanager weisen in der Regel keine Rechteverwaltung wie Flatpak auf. So kommt es dann auch nicht zu Fehlern durch mangelnde Berechtigungen.

  • Kurztipp: Adwaita-Dark in Flatpaks

    Einsortiert in:

    Container-Technologien sind schon sehr spannend. Man kann von ihnen ja halten, was man möchte, nicht abzustreiten ist jedenfalls, dass sie in Zukunft voll viel an Bedeutung gewinnen werden. In diesem Kurztipp möchte ich eine kleine Hilfestellung zu dunklen GTK-Themen in Flatpaks geben – denn durch die Einschachtelung ist es gar nicht so einfach, Adwaita-Dark und Konsorten auf Flatpaks anzuwenden. Als Beispiel-System nutze ich hier openSUSE MicroOS Desktop mit Gnome, prinzipiell sollte diese Anleitung aber auf allen gängigen Distributionen funktionieren. Flatpak kann ja auch unabhängig von den jeweiligen Distributionen verwendbar.

    Nutzern dunkler GTK-Farbschemen dürfte schnell auffallen, dass Anwendungen wie Simplenote oder auch Zettlr (mit nativen Fensterdekorationen) anstelle des systemweit angewandten dunklen Farbschemas helle Bedienelemente aufweisen – das ändert zwar nichts an der Nutzbarkeit, doch die Konsistenz auf dem Desktop ist dann auch dahin. Dabei hilft es dann auch nicht, Einstellungen über die Gsettings bzw. über Werkzeuge wie den dconf-Editor zu ändern. Das Problem sitzt tiefer, ist aber eigentlich keine große Hürde.

    Standardmäßig installieren Flatpaks das nötige Themenpaket für Adwaita-Dark schlicht nicht mit – und was nicht installiert ist, kann nicht auf Anwendungen angewandt werden. Für die Flapaks muss daher noch ein weiteres Paket installiert werden.

    Zunächst sollte man sich einen Überblick über die installierten Flatpak-Anwendungen und -Runtimes verschaffen. Dazu kann man als „normaler“ Nutzer auch ohne Root-Rechte folgende Kommandos ausführen:

    flatpak list

    So werden alle Flatpaks aufgelistet. Für eine gewisse Übersichtlichkeit kann man dann grep verwenden:

    flatpak list | grep "theme"

    Dann werden nur noch die Zeilen ausgegeben, die das Wort „theme“ enthalten. Wir suchen dabei nach dem Paket „org.gtk.Gtk3theme.Adwaita-dark“. Denn nur wenn dieses installiert ist, können Flatpaks auf Adwaita-Dark zugreifen. Das Paket kann einfach nachinstalliert werden:

    flatpak install org.gtk.Gtk3theme.Adwaita-dark

    Wer MicroOS verwendet, sollte Flatpaks prinzipiell im Nutzermodus installieren, dazu muss ein Nutzungsparameter angegeben werden. Übrigens braucht es dann auch kein Passwort, denn die Anwendung wird nur für den jeweiligen Nutzer installiert und nur für diesen bereitstehen.

    flatpak install --user org.gtk.Gtk3theme.Adwaita-dark

    Und das ist auch schon der ganze Trick. Denn dann halten sich Flatpaks eigentlich an den Systemstandard. Sollte dann wider erwarten noch immer das helle Adwaita-Thema verwendet werden, kann man über den dconf-Editor die entsprechende Variable anpassen. Im Flatpak-dconf-Editor navigiert man dazu zu org → gnome → desktop → interface → color-scheme und setzt den Wert dann auf ‚prefer-dark‘.

    Dann kann man die Flatpaks einfach neu starten und das dunkle Adwaita-Schema sollte übernommen werden.

  • Distroboxen in MicroOS

    Einsortiert in:

    Als ich meine Ersteindrücke bezüglich MicroOS dargelegt habe, bin ich auch darauf eingegangen, dass Software bei immutablen Distributionen primär über Container installiert wird oder installiert werden soll. Während für grafische Anwendungen vor allem Flatpak geeignet ist, ist „Distrobox“ meist die erste Wahl, wenn es um Konsolen-basierte Anwendungen geht.

    Ich habe gerade ein bisschen mit der Distrobox herumgespielt. Um eine neue Distrobox anzulegen, habe ich zunächst folgenden Befehl im Terminal ausgeführt:

    distrobox enter

    Entsprechend der Standardeinstellungen wurde dann ein Tumbleweed-Container (mit den nötigsten Paketen) zusammengestellt und im Anschluss betreten. In diesem Container läuft dann also ein openSUSE Tumbleweed, in dem sich zum Beispiel der Paketmanager „zypper“ wie gewohnt verwenden lässt. So kann man dann zum Beispiel den „Midnight Commander“ installieren:

    sudo zypper install mc

    Dieser ist dann nur im Tumbleweed-Container verfügbar, kann also auch nur dort ausgeführt werden. Interessanter Weise legt MicroOS dann auch gleich einen Desktop-Starter für den Container an. Darüber kann dann ein Terminalfenster gestartet werden, in dem die Distrobox schon betreten wurde. So spart man sich also die Zeile, mit der man die bereits erstellte Standard-Distrobox betreten kann:

    distrobox enter

    Insgesamt macht die Integration von Distrobox auf mich als Neueinsteiger einen stimmigen Eindruck. Mit der erhöhten Sicherheit des Systems geht eben teilweise auch ein kleiner Kompromiss in Sachen Komfort einher. Der angelegte Starter ergänzt hier also gut. Ob das jetzt ein Verdienst von MicroOS oder Distrobox ist, weiß ich (noch) nicht.

    Fakt ist aber auch, dass sich durch den immutablen Ansatz eine verstärkte Komplexität in der Software- bzw. Paket-Verwaltung ergibt: Wo bei anderen Distributionen der hauseigene Paketmanager ausreicht (ein gutes Beispiel wäre apt bei Debian) sollte man bei MicroOS eben Flatpak für die GUI, Distrobox für die CLI und transactional-update für sonstige Systempakete verwenden. Umso sinnvoller finde ich es daher, so viel wie möglich zu automatisieren – das ist ja ein Stück weit auch der Grundgedanke hinter MicroOS.

    So viel also erst einmal dazu. 🙂

  • Erste Eindrücke zu openSUSE MicroOS Desktop

    Einsortiert in:

    Gestern Abend habe ich mir openSUSE MicroOS Desktop installiert, mit Gnome, um genau zu sein. MicroOS reiht sich ein in die Familie der immutablen GNU/Linux-Distributionen und ähnelt dahingehend Fedora Silverblue oder auch VanillaOS: Die wichtigen Systemdateien und -verzeichnisse sind für die Nutzer, egal ob root oder nicht, nur lesbar eingehängt und können in der Regel nicht ohne weiteres überschrieben oder verändert werden. Stattdessen arbeiten „unveränderliche“ Distributionen primär mit Containerformaten, die Anwendungen auf der Nutzerebene zur Verfügung stellen sollen. Für grafische Anwendungen nutzt man bei MicroOS also in erster Linie Flatpaks aus dem Flathub. Anwendungen für die CLI lassen sich in virtualisierten bzw. containerisierten Umgebungen installieren, also zum Beispiel in einer Distro- oder Toolbox. Soll eine Anwendung persistenter Teil des unveränderlichen Betriebssystems werden, kann es in einen Snapshot eingebunden werden, über ein transaktionales Update. Nach einem Neustart kann dann der Computer mit diesem neuen Betriebssystem-Abbild gestartet werden.

    Mit dieser Vorgehensweise bieten immutable Distributionen einen großen Sicherheits- und Stabilitätsvorteil, können aber trotzdem sehr aktuell sein: Die kleinen Abbilder des unterliegenden Betriebssystems sind für Distributoren leichter zu warten, da sie überschaubarer sind als herkömmliche Distributionen. Für Nutzer wird das Software-Angebot auf die Container-Lösungen zusammengefasst, wobei allgemeine Paketquellen wie das Flathub eine sinnvolle Vereinfachung darstellen. Insgesamt bieten immutable Distributionen maßgebliche Vorteile für Desktop-Anwender. Diese werden aber nicht unbedingt auf den ersten Blick ersichtlich. Wer sich zum Beispiel die Diskussionen auf den einschlägen FLOSS-Portalen zu diesem Thema anschaut, wird schnell eine gewisse Skepsis feststellen können, die nicht immer begründet ist.

    Auch ich war lange Zeit skeptisch, ob immutable Distributionen wirklich die Zukunft für GNU/Linux darstellen sollten. Doch nachdem ich bereits Silverblue und mittlerweile auch MicroOS ausprobiert habe, kann ich beruhigt sagen: Das Potential, was viele dem immutablen Distributionsansatz zusprechen, ist in jedem Fall gegeben. Meiner Ansicht nach sollte sich jeder ein eigenes Bild von den Immutables machen – besten Falls auf dedizierter Hardware. Sicher, die Entwicklungen in diese Richtung steckt momentan noch in den Kinderschuhen. Nutzbar ist sie aber im Desktop-Bereich insbesondere mit Gnome schon heute. Wer sich also unsicher ist, dem steht eigentlich nichts im Weg, sich selbst ein Bild zu machen.

    Je nach Distribution unterscheiden sich aber auch die unveränderlichen GNU/Linux-Betriebssysteme, vor allem auf technischer Ebene: Fedora Silverblue baut auf dem Veröffentlichungs-Zyklus der Fedora-Hauptdistributionen auf, erscheint also alle sechs Monate. Diese statischen Veröffentlichungen werden dann genau so lang, wie die Fedora-Hauptdistributionen unterstützt. Sobald eine neue Silverblue-Version zur Verfügung steht, sollten Nutzer ein sogenanntes „Rebase“ vornehmen. Dabei wird das unterliegende Betriebssystem auf die neue Version angehoben. Hier fällt also auf: Wer Silverblue nutzt, ist daran gebunden, entsprechend des Support-Zeitraums Aktualisierungen vorzunehmen; Anwendungs-Updates kommen dabei noch oben drauf. Ein weiterer Unterschied zu MicroOS liegt darin, das Silverblue auf rpm-ostree als Layer-Technologie, also für die Erstellung der Betriebssystem-Abbilder setzt.

    openSUSE geht mit MicroOS einen etwas anderen Weg und setzt darauf, so viel wie nur möglich zu automatisieren: MicroOS basiert auf dem rollenden Tumbleweed-Zeig der Distribution, kann also fortlaufend aktualisiert werden. Hier sind keine zyklischen Versionssprünge nötig. Dabei versucht MicroOS entsprechend des Namens das Basis-Abbild so klein wie irgend möglich zu halten, „Micro“ eben. MicroOS aktualisiert sich stets von selbst und legt bei jeder Aktualisierung einen btrfs-Snapshot als neues Abbild an. Sollte beim Boot-Vorgang dann etwas schief laufen, fällt MicroOS automatisch auf den letzten funktionierenden Snapshot zurück. MicroOS ist also fortlaufend auf dem neuesten Stand der Software- und System-Entwicklung, aber trotzdem sehr gut abgesichert.

    MicroOS als rollende immutable Distribution löst damit das größte Problem rollender Distributionen: Wer openSUSE Tumbleweed, Arch Linux oder Debian Sid nutzen möchte, der muss manchmal gewisse Kompromisse hinnehmen, wenn es um die Stabilität oder Verlässlichkeit der jeweiligen Distribution angeht. Wer nun aber auf MicroOS setzt, der muss sich „keine Sorgen“ um sein System machen – zumindest wenn es nach den Entwicklern der Distribution geht. Man merkt mir vielleicht an: Ich bin ziemlich angetan von diesem System. Theoretisch könnte ich es jetzt einfach vergessen – denn es aktualisiert sich ja fortlaufend selbst, so weit ich weiß gilt das auch für Flatpaks. 🙂

    Dem entsprechend bin ich gespannt, wie sich openSUSE in Zukunft als immutable Distribution weiterentwickelt.