Kategorie: Technik

Aktualisiertes AppArmor-Profil für Sublime Text 4

· · 0 Kommentare

Nach der Aktualisierung auf Version 4 wollte Sublime Text mit dem alten AppArmor-Profil nicht mehr starten. Ein Blick ins Log half, die Problemstellen zu lokalisieren und das Profil anzupassen:

# 2020-05-11 athul/initial
# 2020-09-29 athul/replaced abstractions/evince
# 2021-07-26 athul/changed permissions for /opt/sublime_text/sublime_text from "mr" to "mrix",
#   added settings for /opt/sublime_text/plugin_host-3.3, /opt/sublime_text/plugin_host-3.8
#   chandged permissions for /opt/sublime_text/** from "r" to "mr", removed /opt/sublime_text/plugin_host
# 2021-08-19 athul/added write permission to /tmp/*

#include <tunables/global>

/opt/sublime_text/sublime_text {
  #include <abstractions/X>
  #include <abstractions/base>
  #include <abstractions/dbus-session-strict>
  #include <abstractions/fonts>

  deny network,

  /opt/sublime_text/ r,
  /opt/sublime_text/** mr,
  /opt/sublime_text/plugin_host-3.3 mrix,
  /opt/sublime_text/plugin_host-3.8 mrix,
  /opt/sublime_text/sublime_text mrix,
  /proc/filesystems r,
  /usr/share/** r,
  /usr/bin/perl mrix,
  /usr/bin/sassc mrix,
  owner /dev/shm/* rwl,
  owner /run/user/** rw,
  owner /tmp/* w,
  @{HOME}/** rwk,
  @{HOME} rw,
}

Es musste die Berechtigung für Sublime Text um "ix" (execute and inherit the current profile) ergänzt, die Einstellungen für den Plugin-Host geändert und die Berechtigungen für die Dateien unterhalb von "/opt/sublime_text/" um "m" (memory map executable) erweitert werden.

Versionshistorie:

2021-08-19: Fehlende Berechtigung zum Schreiben in "/tmp" ergänzt
2021-08-09: Aktualisierung für Sublime Text 4


Happy Birthday und Danke, Debian!

· · 0 Kommentare

Vor wenigen Tagen hatte das Debian-Projekt 28. Geburtstag - nachträglich Herzlichen Glückwunsch!

Ich bin vor rund 20 Jahren auf Debian gestoßen, als ich genervt von Suse auf der Suche nach einer Alternative für einen Intranet-Server war. Um die Geschichte zusammenzufassen: heruntergeladen, installiert und nie wieder untreu geworden.

Seit rund zwei Jahren läuft Debian auch auf dem heimischen Arbeitsplatz und ich habe mich schon mehr als einmal gefragt, warum ich den Umstieg nicht früher gewagt habe - wer sich für Details interessiert, kann sie im Beitrag "Debian - ein Erfahrungsbericht" nachlesen.

Herzlichen Dank an alle, die im Laufe der Jahre an Debian mitgewirkt, entwickelt und Zeit und Energie in das Projekt investiert haben!


Warum Snapshots nur temporär verwendet werden sollten

· · 0 Kommentare

Snapshots sind eine tolle Sache: einen Snapshot erstellen, etwas ausprobieren und entweder wird das Ergebnis für die Ewigkeit konserviert (indem der Snapshot dauerhaft in die virtuelle Maschine übernommen wird) oder es geht zurück auf den Stand des Snapshots, weil man die Änderung nicht behalten möchte.

Da Snapshots sowohl Speicherplatz benötigen als auch Leistung kosten sollte darauf geachtet werden, sie lediglich temporär einzusetzen.

Hier ein an manchen Stellen vereinfachter Erklärungsversuch, die verwendeten Farben bedeuten folgendes:

Ausgangsszenario

Eine virtuelle Maschine speichert ihre Festplatte in einer Datei "Festplatte" (dazu kommt noch die ein oder andere Verwaltungsdatei, diese sind aber für die Betrachtung unerheblich). Diese Festplatte ist in viele Blöcke einer festen Größe unterteilt, in der die Daten liegen.

Diese Datei hat eine maximale Größe, welche der für die Festplatte festgelegten Kapazität entspricht. Sämliche Lese- und Schreibzugriffe finden innerhalb der Datei "Festplatte" statt.

Snapshot "Snapshot 1"

Nun wird ein Snapshot "Snapshot 1" angelegt. Ab diesem Moment wird auf die Datei "Festplatte" nur noch lesend zugegriffen, alle Änderungen die Blöcke der Festplatte betreffend (neue Dateien, geänderte Dateien etc ...) werden in der Datei "Snapshot 1" gespeichert.

Nach einiger Zeit der Nutzung ergibt sich folgendes Bild:

Für jeden Lesezugriff muß die virtuelle Maschine nun schauen, ob sie einen angefragten Block aus der Datei "Festplatte" (Blöcke 2, 4 und 5) oder aus der Datei "Snapshot 1" (Blöcke 1, 3, 6, 7 und 8) nehmen muß.

Mit jedem Schreibzugang, der einen in "Snapshot 1" noch nicht geänderten Block betrifft, wächst die Datei "Snapshot 1". Im Extremfall, wenn jeder Block der Festplattte geändert wurde, wird die Datei "Snapshot 1" so groß wie die ursprüngliche Datei "Festplatte". Im Beispiel ist der benötigte Platz von ursprünglich 8 Blöcken auf 13 Blöcke angewachsen.

Snapshot "Snapshot 2"

Nun wird ein weiterer Snapshot "Snapshot 2" angelegt. In diesem Moment wird auf die Dateien "Festplatte" und "Snapshot 1" nur noch lesend zugegriffen, alle Änderungen die Blöcke der Festplatte betreffend werden in der Datei "Snapshot 2" gespeichert.

Nach einiger Zeit der Nutzung ergibt sich folgendes Bild:

Für jeden Lesezugriff muß die virtuelle Maschine nun schauen, ob sie einen angefragten Block aus der Datei "Festplatte" (Block 2), der Datei "Snapshot 1" (Block 7) oder der Datei "Snapshot 2" (Blöcke 1, 3, 4, 5, 6 und 8) nehmen muß.

Mit jedem Schreibzugang, der einen in "Snapshot 2" noch nicht geänderten Block betrifft, wächst die Datei "Snapshot 2". Im Extremfall, wenn jeder Block der Festplattte geändert wurde, wird die Datei "Snapshot 2" so groß wie die ursprüngliche Datei "Festplatte". Im Beispiel ist der benötigte Platz von ursprünglich 8 Blöcken auf 19 Blöcke angewachsen, d.h. es wird bereits mehr als der doppelte Platz der Maximalgröße von "Festplatte" verwendet.

Problematik

Wenn sich ein Block oft ändert, wird für diesen nun auch dreifach Speicherplatz belegt: in der Datei "Festplatte", in der Datei "Snapshot 1" und in der Datei "Snapshot 2".

Bei Lesevorgängen muß immer geschaut werden, in welcher der drei Dateien die aktuelle Version des Blocks zum Zurückliefern vorhanden ist.

Löschen von "Snapshot 1"

Wenn man nun sicher ist, daß alles, was zu dem Zeitpunkt, als "Snapshot 2" erstellt wurde funktioniert, kehrt man i.d.R. nie wieder zu "Snapshot 1" zurück.

Als Konsequenz daraus löscht man in der Verwaltungsoberfläche der Virtualisierungssoftware "Snapshot 1". Die Virtualisierungssoftware überträgt alle Blöcke aus "Snapshot 1" zurück an die entsprechenden Stellen von "Festplatte" (Blöcke 1, 3, 6, 7 und 8) und löscht anschließend die Datei "Snapshot 1".

Als Ergebnis ergibt sich folgendes Bild:

Die Leistung wird besser, weil bei Lesezugriffen nur noch geschaut werden muss, ob ein Block aus "Festplatte" (Blöcke 2 und 7) oder "Snapshot 2" (Blöcke 1, 3, 4, 5, 6 und 8) gelesen werden muß und der Speicherplatz, den die Datei "Snapshot 1" bisher benötigt hat, ist wieder verfügbar. Im Beispiel ist der benötigte Platz von 19 Blöcken auf 14 Blöcke geschrumpft.


Nextcloud meldet nach Update "APCu not available for local cache"

· · 13 Kommentare

Nach dem Update von Nextcloud 21.0.2 auf 21.0.3 lief das "occ"-Kommando auf einen Fehler:

$ php occ upgrade
An unhandled exception has been thrown:
OC\HintException: [0]: Memcache \OC\Memcache\APCu not available for local cache (Is the matching PHP module installed and enabled?)

Keine Ahnung, warum dies bis einschließlich Nextcloud 21.0.2 reibungslos funktioniert hat, die Lösung fand sich aber recht schnell in der Nextcloud-Dokumentation:

Der Datei "/etc/php/7.3/cli/php.ini" musste der Eintrag

apc.enable_cli=1

hinzugefüht werden, dann war die Ausführung des "occ"-Kommandos wieder probemlos möglich.

Alternativ sollte lt. Dokumentation auch das Hinzufügen des Parameters

--define apc.enable_cli=1

zur Kommandozeile ausreichen.


Thema für GTK-Anwendungen erzwingen

· · 0 Kommentare

Auch wenn global ein helles Thema gewählt ist, können Anwendungen (wie z.B. "Eye of Gnome") trotzdem ein dunkles Schema verwenden, ohne dem Benutzer eine diesbezügliche Wahlmöglichkeit zu bieten.

Für diese Anwendungen lässt sich die gewünschte Darstellung  erzwingen, in dem das  Thema mitsamt Variante dem Programmaufruf vorangestellt wird:

$ GTK_THEME=Materia-light-compact:light eog