y0o.de · GNU/Linux Nachrichten u.Ä.

🔒
❌ Über y0o.de
Es gibt neue verfügbare Artikel. Klicken Sie, um die Seite zu aktualisieren.
Heute — 18. Januar 2022Blogs

Edge ISO für Linux Mint 20.3 ist verfügbar – mit Kernel 5.13

18. Januar 2022 um 07:45
Von: jdo

Manche Hardware ist zu neu, um sie mit Linux-Kernel 5.4 LTS booten zu können. Dieser Kernel kommt bei Linux Mint 20.3 Una zum Einsatz. Damit sich die Linux-Distribution auch mit neueren Rechnern betreiben lässt, gibt es nun ein Edge-ISO, das Kernel 5.13.0-25 mit sich bringt. In den Kommentaren der Ankündigung taucht die Frage auf, ob das Team die Kernel-Richtlinie für die dritte Punkt-Version nicht ändern wolle. Clement Lefebvre hat darauf geantwortet, dass 5.13.0-23 auf seiner neuen Hardware nicht gestartet ist. […]

Der Beitrag Edge ISO für Linux Mint 20.3 ist verfügbar – mit Kernel 5.13 ist von bitblokes.de.

Gestern — 17. Januar 2022Blogs

digiKam 7.5.0 ist veröffentlicht – Fotos mit Open Source verwalten

17. Januar 2022 um 07:17
Von: jdo

Das Team um die kostenlose Fotoverwaltungs-Software digiKam hat seit der letzten Version sehr viele Bugs aus dem Programm vertrieben. Insgesamt wurden 700 Dinge in Bugzilla geschlossen. Außerdem gibt das Team an, dass digiKam 7.5.0 benutzerfreundlicher ist. digiKam und Showfoto wurden seit Beginn des Projekts vom KDE-Übersetzerteam in viele Sprachen übersetzt. 20 Jahre Lokalisierung bedeutet mehr als 50 verschiedenen Sprachen. Das ist schon beeindruckend. In dieser Version wurden den “Rechts nach Links”-Sprachen besondere Aufmerksamkeit geschenkt. Laut eigenen Angaben ist das eine […]

Der Beitrag digiKam 7.5.0 ist veröffentlicht – Fotos mit Open Source verwalten ist von bitblokes.de.

Labor-Umgebung mit Ansible in KVM erstellen

17. Januar 2022 um 07:00

Inspiriert durch die Artikel von Ricardo Geradi [1] und Alex Callejas [3] schreibe ich diesen, um zu erklären, wie mithilfe von Ansible eine Labor-Umgebung bestehend aus einer oder mehreren virtuellen Maschinen (VMs) auf einem KVM-Hypervisor provisioniert werden kann.

Dabei handelt es sich weniger um ein Tutorial, sondern mehr um eine exemplarische Beschreibung einer möglichen Vorgehensweise, die euch als Vorlage für die eigene Umgebung dienen kann.

Ich gehe nicht darauf ein, wie KVM oder Ansible installiert werden. Hierzu verweise ich auf die Dokumentation der jeweiligen Projekte und der verwendeten Linux-Distributionen.

Motivation

Um Anwendungen zu testen, benötigt man in der Regel ein Betriebssystem, auf welchem diese ausgeführt werden können. Ein Betriebssystem läuft dieser Tage meist innerhalb einer virtuellen Maschine (VM). Um bei Tests stets gleiche Rahmenbedingungen zu haben, wird empfohlen, für jeden Test eine neue VM mit einer definierten Konfiguration zu provisionieren, die geplanten Tests durchzuführen, die Ergebnisse zu sichern und die VM zu dekommissionieren.

Möchte man Infrastrukturdienste testen, werden häufig gleich mehrere VMs benötigt. Diese werden auch als Labor-Umgebung bezeichnet.

Um nicht unnötig Zeit mit der Provisionierung der VMs zu verlieren — immerhin möchte man ja seine Anwendungen bzw. Dienste testen — bietet es sich an, diesen Prozess zu automatisieren.

Doch warum mit Ansible und nicht mit [hier Lieblings-Werkzeug eurer Wahl einsetzen]?

Viele Wege führen nach Rom. Und es gibt vermutlich ähnlich viele Werkzeuge, um eine Labor-Umgebung in KVM zu provisionieren. Ich habe mich in diesem Fall für Ansible entschieden, da:

  • Ich fast täglich damit arbeite.
  • Mit ansible-galaxy role init erstellte Rollen meiner bescheidenen Meinung nach (mbMn) eine schöne Struktur zur Organisation des Codes vorgeben.
  • Mit ansible-vault ein Werkzeug dabei ist, um Dateien mit sensiblen Informationen zu verschlüsseln und diese im weiteren Verlauf einfach zu nutzen.
  • Ich meine YAML-Dateien nächstes Jahr leichter lesen und verstehen kann als meine Shell-Skripte.
  • Ich in einem zukünftigen Artikel zeigen möchte, wie man mit Ansible eine Labor-Umgebung in einem VMware vSphere Cluster provisioniert.

Umgebung

KVM-Hypervisor: Debian 11 Bullseye

Die .qcow2-Image-Dateien für die VMs werden auf dem KVM-Hypervisor im Verzeichnis /var/lib/libvirt/images/ vorgehalten.

Getestete Ansible Versionen:

  • ansible 2.10.8 ( auf Debian 11 Bullseye)
  • ansible [core 2.12.1] (auf Fedora 35)

Die Verzeichnisstruktur für meine Ansible-Umgebung entspricht der aus dem Artikel Linux-Benutzerkonten mit Ansible verwalten, wie sie im dortigen Abschnitt Vorbereitung beschrieben ist.

Die im Laufe dieses Artikels provisionierte Labor-Umgebung wird aus einer RHEL-7 und einer RHEL-8-VM bestehen. Selbstverständlich ist es möglich, durch einfache Anpassungen weitere VMs sowie andere Linux-Distributionen zu provisionieren.

Vorarbeit

Ricardo Geradi [1] und Alex Callejas [3] beziehen in ihren Artikeln die qcow2-Images, welche sie als Vorlage (engl. Template) für weitere VMs verwenden, aus diversen Internet-Quellen. Ich bin kein Freund davon, mir Images aus dem Netz zu laden und zu nutzen, für die es keine ordentliche Dokumentation gibt, mit welchen Paketen und Einstellungen diese erzeugt wurden.

Wer kauft schon gern die Katze im Sack? Daher erstelle ich mir meine Vorlagen selbst. Dazu führe ich für jede Distribution, für die ich eine Vorlage erstellen möchte, eine manuelle Installation durch. Um die Vorlagen unter all den anderen VMs leicht identifizieren zu können, gebe ich ihnen Namen wie z.B.:

  • rhel7-template
  • rhel8-template
  • debian11-template

Dabei hinterlege ich beim User root bereits den SSH-Public-Key, den ich später mit Ansible verwenden möchte, um diese Systeme weiter zu konfigurieren. Dies tue ich zwar bisher. Es ist für die Verwendung der hier beschriebenen Rolle nicht erforderlich.

Möchte ich eine Vorlage aktualisieren, fahre ich die dazugehörige VM hoch, führe ein Paket-Update durch, fahre die VM wieder herunter und bin fertig. Dies mache ich in der Regel alle paar Monate, wenn mir das Paket-Update bei neu provisionierten VMs zu lange dauert und spätestens nach Erscheinen eines neuen Minor-Release.

Die Ansible-Rolle

Eine Ansible-Rolle wird mit dem Befehl ansible-galaxy role init role_name initialisiert. In meinem Fall sieht dies wie folgt aus:

$ ansible-galaxy role init kvm_provision_lab
- Role kvm_provision_lab was created successfully
$ tree kvm_provision_lab
kvm_provision_lab
├── defaults
│   └── main.yml
├── meta
│   └── main.yml
├── README.md
├── tasks
│   └── main.yml
├── templates
└── vars
    └── main.yml

In obiger Ausgabe fehlen die Verzeichnisse Files und Handlers. Diese hatte ich bereits gelöscht, da sie nicht benötigt werden. Die erstellte Verzeichnisstruktur kann, je nach verwendeter Version von ansible-galaxy, leicht unterschiedlich aussehen. Benötigt werden in diesem Beispiel nur die oben dargestellten Verzeichnisse und Dateien. Streng genommen können das Verzeichnis meta und die Datei README.md ebenfalls entfernt werden, wenn man nicht vorhat, die Rolle zu veröffentlichen. Ich behalte beide bei und nutze die Dateien zur Dokumentation der Rolle.

Variablen

Es ist gute Praxis alle Variablen, die von einer Ansible-Rolle verarbeitet werden, in der Datei defaults/main.yml zu dokumentieren und mit Standardwerten zu versehen. Genannte Datei hat hier folgenden Inhalt:

$ cat -n defaults/main.yml 
     1	---
     2	libvirt_pool_dir: "/var/lib/libvirt/images"
     3	vm_root_pass: "123456"
     4	ssh_key: "/path/to/ssh-pub-key"
     5	
     6	guests:
     7	  test:
     8	    vm_ram_mb: 512
     9	    vm_vcpus: 1
    10	    vm_net: default
    11	    os_type: rhel7
    12	    file_type: qcow2
    13	    base_image_name: rhel7-template
    14	    vm_template: "rhel7-template"
    15	    second_hdd: false
    16	    second_hdd_size: ""
    17	  test2:
    18	    vm_ram_mb: 512
    19	    vm_vcpus: 1
    20	    vm_net: default
    21	    os_type: rhel8
    22	    file_type: qcow2
    23	    base_image_name: rhel8-template
    24	    vm_template: "rhel8-template"
    25	    second_hdd: true
    26	    second_hdd_size: "100M"

In Zeile 2-4 werden Variablen definiert, die unabhängig von einzelnen VMs für die gesamte Rolle gelten. Dies sind der Speicherort für Image-Dateien, das Passwort für den Root-Benutzer der VMs, sowie der Pfad zu dem SSH-Public-Key, welcher beim Root-Benutzer hinterlegt werden soll.

In Zeile 6 beginnt ein sogenanntes Ansible-Dictionary (siehe [6]) namens guests. Es enthält als Keys die Namen der VMs (hier test und test2) und ordnet diesen diverse Variablen als Werte zu (z.B. vm_ram_mb). Die hierfür gewählten Strings müssen gültige Ansible-Variablen sein (siehe [7]).

Die einzelnen Variablen kurz erklärt:

  • vm_ram_mb gibt die Größe des Gast-Arbeitsspeichers in Megabyte (MB) an.
  • vm_vcpus spezifiziert die Anzahl CPUs der VM.
  • vm_net bezeichnet das KVM-Netzwerk, mit dem die VM verbunden wird.
  • os_type wird aktuell noch nicht verwendet.
  • file_type gibt den Typ der Image-Datei an.
  • base_image_name verweist auf den Namen der zu verwendenden Vorlage, die zuvor manuell installiert wurde.
  • vm_template referenziert eine Jinja2-Template-Datei, welche wir uns im nächsten Abschnitt anschauen werden.
  • second_hdd kann auf true oder false gesetzt werden und bestimmt, ob einer VM eine zweite Festplatte hinzugefügt werden soll.
  • second_hdd_size gibt die Größe der zweiten Festplatte in Megabyte (MB) an.

Führt man diese Rolle mit einem Playbook aus, ohne eigene Variablen zu definieren, werden also zwei VMs mit den Namen test und test2 sowie den obigen Parametern erstellt.

Um die Rolle möglichst flexibel einsetzen und wiederverwenden zu können, werden die gewünschten Labor-Umgebungen in separaten Dateien definiert. Für mein RHEL-Lab habe ich die benötigten Variablen in die Datei vars/rhel_lab.yml geschrieben, welche ich mit ansible-vault create vars/rhel_lab.yml erstellt habe. So bleiben mein gewähltes Passwort sowie Pfad zu und Name von meinem SSH-Public-Key vor neugierigen Blicken geschützt. Der Inhalt der Datei entspricht vom Aufbau her jedoch dem aus obigem Code-Block der defaults/main.yml. Wie die Datei rhel_lab.yml genutzt wird, wird in Abschnitt „Das Playbook“ erläutert.

Templates

In der KVM-Terminologie wird eine VM auch als Gast-Domain (engl. guest domain) bezeichnet. Die Definition der Gast-Domain kann in Form einer XML-Datei erfolgen. In diesem Abschnitt werde ich zeigen, wie man die Konfiguration einer bestehenden VM in eine XML-Datei schreibt, um diese anschließend als Template für neue VMs zu benutzen.

Im Vorfeld habe ich die VMs rhel7-template und rhel8-template manuell installiert. Diese werde ich nun nutzen, um daraus Jinja2-Templates abzuleiten, welche ich innerhalb der Rollen-Verzeichnisstruktur im Verzeichnis templates ablege. Der folgende Codeblock zeigt den Befehl exemplarisch für das rhel7-template:

$ sudo virsh dumpxml rhel7-template >templates/rhel7-template.xml.j2

Das rhel8-template.xml.j2 wird auf die gleiche Weise erzeugt. Der Inhalt wird im Folgenden auszugsweise dargestellt:

<domain type='kvm'>
  <name>rhel8-template</name>
  <uuid>cb010068-fe32-4725-81e8-ec24ce237dcb</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://redhat.com/rhel/8-unknown"/>
    </libosinfo:libosinfo>
  </metadata>
  <memory unit='KiB'>2097152</memory>
  <currentMemory unit='KiB'>2097152</currentMemory>
  <vcpu placement='static'>1</vcpu>
[...]
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/rhel8-template.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <target dev='hdb' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
[...]
    <interface type='network'>
      <mac address='52:54:00:0c:8d:05'/>
      <source network='default'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
[...]
  </devices>
</domain>

Die Template-Dateien sind zu bearbeiten, um aktuell statisch konfigurierte Werte durch Variablen zu ersetzen. Die zu bearbeitenden Zeilen sehen anschließend wie folgt aus:

  • <name>{{ item.key }}</name>
  • <memory unit='MiB'>{{ item.value.vm_ram_mb }}</memory>
  • <vcpu placement='static'>{{ item.value.vm_vcpus }}</vcpu>
  • <source file='{{ libvirt_pool_dir }}/{{ item.key }}.qcow2'/>
  • <source network='{{ item.value.vm_net }}'/>

Darüber hinaus sind weitere Zeilen, welche für jede VM einmalig sind, aus den Template-Dateien zu löschen:

  • <uuid>...</uuid>
  • <mac address='...'/>

In der fertigen rhel8-template.xml.j2-Datei sieht es dann wie folgt aus:

<domain type='kvm'>
  <name>{{ item.key }}</name>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://redhat.com/rhel/8-unknown"/>
    </libosinfo:libosinfo>
  </metadata>
  <memory unit='MiB'>{{ item.value.vm_ram_mb }}</memory>
  <vcpu placement='static'>{{ item.value.vm_vcpus }}</vcpu>
[...]
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='{{ libvirt_pool_dir }}/{{ item.key }}.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </disk>
[...]
    <interface type='network'>
      <source network='{{ item.value.vm_net }}'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
[...]
  </devices>
</domain>

Solltet ihr zu diesem Abschnitt noch Fragen haben, weil z.B. etwas unverständlich ist, stellt diese bitte in den Kommentaren oder meldet euch per E-Mail. Ich werde den Abschnitt dann je nach Bedarf ergänzen.

Tasks

Als Nächstes stelle ich die Tasks vor, welche von dieser Rolle ausgeführt werden. Dabei beginne ich mit dem Inhalt der Datei tasks/main.yml, deren Inhalt ich nach dem folgenden Codeblock erläutern werde.

$ cat -n tasks/main.yml 
     1	---
     2	# tasks file for kvm_provision_lab
     3	- name: Ensure requirements are in place
     4	  apt:
     5	    name:
     6	      - libguestfs-tools
     7	      - python3-libvirt
     8	    state: present
     9	  become: yes
    10	
    11	- name: Get VMs list
    12	  community.libvirt.virt:
    13	    command: list_vms
    14	  register: existing_vms
    15	  changed_when: no
    16	
    17	- name: Copy base image
    18	  copy:
    19	    dest: "{{ libvirt_pool_dir }}/{{ item.key }}.{{ item.value.file_type }}"
    20	    src: "{{ libvirt_pool_dir }}/{{ item.value.base_image_name }}.{{ item.value.file_type }}"
    21	    force: no
    22	    remote_src: yes
    23	    mode: 0660
    24	    group: libvirt-qemu
    25	  register: copy_results
    26	  with_dict: "{{ guests }}"
    27	
    28	- name: Create VMs if not exist
    29	  include_tasks: create_vms.yml
    30	  when: "item.key not in existing_vms.list_vms"
    31	  with_dict: "{{ guests }}"

Der Task in Zeile 3-9 stellt sicher, dass die notwendigen Voraussetzungen erfüllt sind, um sich mit libvirt verbinden zu können. Der Paketname libguestfs-tools existiert unter CentOS Stream, Debian und RHEL. Unter Fedora heißt das Paket guestfs-tools. Der Name muss an die entsprechende Distribution angepasst werden.

In Zeile 11-15 wird das Modul community.libvirt.virt verwendet, um die Liste der bereits existierenden VMs abzurufen und in der Variablen existing_vms zu speichern. Diese wird später genutzt, um nur dann eine VM zu provisionieren, wenn nicht bereits eine VM mit dem gleichen Namen existiert. Es ist quasi ein schmutziger Trick, um der Rolle ein wenig Idempotenz einzuhauchen. Da mit diesem Task nur Informationen abgefragt werden, jedoch keinerlei Änderungen vorgenommen werden, setzt man changed_when: no.

Das Copy-Modul in Zeile 17-26 kopiert die qcow2-Image-Dateien an den vorgesehenen Zielort und setzt Zugriffsrechte entsprechend. Zeile 19 sorgt dafür, dass die Zieldatei den Namen der neuen VM beinhaltet. Da das Copy-Modul bereits idempotent arbeitet, werden die Dateien nur kopiert, wenn das Ziel nicht bereits existiert. Das Ergebnis des Kopiervorgangs wird in copy_results gespeichert.

Der letzte Task führt die Task-Datei create_vms.yml für die VMs aus, die nicht bereits existieren. Dafür sorgt die Bedingung when: "item.key not in existing_vms.list_vms", die diesem Task zu Idempotenz verhilft. Das Playbook selbst hat folgenden Inhalt:

$ cat -n tasks/create_vms.yml 
     1	---
     2	- name: Configure the image
     3	  command: |
     4	    virt-customize -a {{ libvirt_pool_dir }}/{{ item.key }}.qcow2 \
     5	    --hostname {{ item.key }} \
     6	    --root-password password:{{ vm_root_pass }} \
     7	    --ssh-inject 'root:file:{{ ssh_key }}' \
     8	    --uninstall cloud-init --selinux-relabel
     9	  when: copy_results is changed
    10	
    11	- name: Define VMs
    12	  community.libvirt.virt:
    13	    command: define
    14	    xml: "{{ lookup('template', '{{ item.value.vm_template }}.xml.j2') }}"
    15	
    16	- name: Create second disk images if needed
    17	  command: |
    18	    qemu-img create -f {{ item.value.file_type }} \
    19	    {{ libvirt_pool_dir }}/{{ item.key }}-vdb.{{ item.value.file_type }} {{ item.value.second_hdd_size }}
    20	  become: yes
    21	  when: item.value.second_hdd|bool == true
    22	
    23	- name : Attach second disk image to domain
    24	  command: |
    25	    virsh attach-disk {{ item.key }} \
    26	    --source "{{ libvirt_pool_dir }}/{{ item.key }}-vdb.{{ item.value.file_type }}" \
    27	    --target vdb \
    28	    --persistent
    29	  become: yes
    30	  when: item.value.second_hdd|bool == true
    31	
    32	- name: Ensure VMs are startet
    33	  community.libvirt.virt:
    34	    name: "{{ item.key }}"
    35	    state: running
    36	  register: vm_start_results
    37	  until: "vm_start_results is success"
    38	  retries: 15
    39	  delay: 2

Der Task in Zeile 2-9 konfiguriert den Inhalt der qcow2-Image-Datei. Die Bedingung when: copy_results is changed stellt sicher, dass dies nur passiert, wenn die Image-Datei zuvor an ihren Zielort kopiert wurde. Damit wird sichergestellt, dass nicht eine bereits vorhandene Image-Datei einer existierenden VM nochmals verändert wird. Der Task konfiguriert den Hostnamen, setzt das Root-Passwort und hinterlegt den SSH-Public-Key.

Der nächste Task ab Zeile 11 definiert/erstellt die neue VM aus den XML-Template-Dateien.

Die beiden Tasks in den Zeilen 16-30 fügen einer VM eine zweite Festplatte hinzu, wenn dies in defaults/main.yml bzw. vars/rhel_lab.yml entsprechend definiert wurde.

Der letzte Task sorgt schließlich dafür, dass die neu erstellten VMs eingeschaltet werden.

Das Playbook

Im Vergleich zu den Dateien mit den einzelnen Tasks fällt das Playbook eher kurz aus:

 cat -n kvm_provision_rhel_lab.yml 
     1	---
     2	- name: Provision RHEL lab VMs
     3	  hosts: localhost
     4	  vars_files:
     5	    - roles/kvm_provision_lab/vars/rhel_lab.yml
     6	  tasks:
     7	    - name: Run role kvm_provision_lab
     8	      include_role:
     9	        name: kvm_provision_lab

In Zeile 3 ist der KVM-Hypervisor anzugeben, auf dem die Rolle ausgeführt werden soll. Dies kann, wie in meinem Fall, der gleiche Host wie der Ansible-Control-Node sein.

In Zeile 4 und 5 wird die Datei geladen, welche die Variablen für die zu erstellende Laborumgebung enthält. Ohne diese Anweisung werden die Werte aus defaults/main.yml verwendet.

Abschließend wird die Ansible-Rolle inkludiert. Dies ist auch schon alles.

Zusammenfassung

Das Schreiben dieses Artikels hat deutlich länger gedauert als die Erstellung der eigentlichen Ansible-Rolle zur Erstellung einer Laborumgebung unter KVM.

Die einzelnen Abschnitte beschreiben das Vorgehen und die Bestandteile der Rolle im Detail. Ich hoffe, damit deren Funktionsweise deutlich gemacht zu haben.

Ich kann nun meine Labor-Umgebungen in Dateien wie rhel_lab.yml, debian_lab.yml, etc. definieren und die Rolle dazu verwenden, diese zu provisionieren. So steht mir in kurzer Zeit eine frische Testumgebung bereit. Und zwar jedes Mal aufs neue, wenn ich sie benötige.

Wenn euch dieser Artikel dabei hilft, eigene Labor-Umgebungen mithilfe von Ansible zu provisionieren freut mich dies umso mehr.

Quellen und weiterführende Links

  1. Build a lab in 36 seconds with Ansible. Ricardo Gerardi (Red Hat, Sudoer). Enable Sysadmin. 2021-10-22.
  2. 8 Linux virsh subcommands for managing VMs on the command line. Ricardo Gerardi (Red Hat, Sudoer). Enable Sysadmin. 2021-09.09.
  3. Build a lab in five minutes with three simple commands. Alex Callejas (Red Hat). Enable Sysadmin. 2021-08-20.
  4. Ansible Create KVM Guests
  5. community.libvirt.virt – Manages virtual machines supported by libvirt
  6. Ansible Dictionary Variables. URL: https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#dictionary-variables
  7. Creating valid variable names. URL: https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#creating-valid-variable-names

Ältere BeiträgeBlogs

(x)Ubuntu 22.04 (Jammy Jellyfish) im Ausblick

16. Januar 2022 um 12:59
Von: Gerrit

Im April diesen Jahres ist es wieder soweit. Ubuntu und die offiziellen Derivate veröffentlichen eine neue LTS der beliebten Distribution. Mithin das wichtigste Ereignis im Linux-Kalender. Zeit mal einen kleinen Ausblick zu nehmen.

Das Release der neuen LTS von Ubuntu hat sicherlich die größte Breitenwirkung aller Linux-Distributionen. Die große Mehrheit der Linux-Anwender nutzt Ubuntu, eines der offiziellen Derivate oder eines jener inoffiziellen Derivate wie beispielsweise Linux Mint oder elementary OS. Hier treffen zwei Jahre Entwicklung am Linux-Desktop auf den Anwender und damit die Wirklichkeit.

Noch ist einiges im Fluss, denn der Feature Freeze steht erst am 24. Februar an, aber einige Aussagen lassen sich bereits jetzt treffen. Große Umbrüche sind dieses Jahr nicht zu erwarten, aber einige Änderung an der Oberfläche der jeweiligen Derivate und unter der Haube stehen an.

Die größte und wichtigste Neuerung. Es wird nach Jahren einen neuen Installer geben. Unter der Haube lässt man es hingegen eher bedächtig angehen und wird den Linux Kernel 5.15 nutzen, der bereits jetzt bei vielen Rolling Release-Distributionen zum Einsatz kommt. Allerdings ist das wenig dramatisch, weil Ubuntu traditionell im Laufe des Lebenszyklus der Distribution neuere Kernel-Versionen an die Anwender verteilt.

Das Hauptderviat Ubuntu wird standardmäßig Wayland nutzen und damit die endgültige Abkehr von X.org einleiten. Es dürfte sicherlich spannend werden, ob Wayland wirklich schon reif für den produktiven Einsatz bei Massen von normalen Anwendern ist. Bei der Desktopumgebung fährt man eine Zwischenmethode, die bereits bei früheren Releases zum Einsatz kam. Eine aktuelle GNOME Shell (vermutlich 42) wird mit älteren Apps kombiniert, da Ubuntu noch nicht auf Gtk4-Apps umsteigen möchte. Optisch gestaltet man die Shell weiterhin im Stil von Unity. Anwender müssen sich also nicht umorientieren. Firefox ist standardmäßig als Snap enthalten. In den Paketquellen ist aber immer noch ein normales Firefox-Paket im Bereich main enthalten. Die Anwender haben also die Wahl. Ansonsten gibt es nur wenige Änderungen gegenüber Ubuntu 21.10 – was aber für ein LTS-Release nicht unüblich ist.

Kubuntu aktualisiert wie üblich KDE Frameworks, KDE Plasma und die Programmsammlung KDE Gear. KDE Gear wird vermutlich in der Version 21.12 aus dem vergangenen Dezember ausgeliefert werden. KDE Plasma ist bereits in einer Vorschauversion von 5.24 enthalten. Diese Version wird es somit mit Sicherheit ins Release schaffen. Diese Version könnte möglicherweise wieder eine LTS-Version mit Upstream-Unterstützung werden. Mit Sicherheit ist Kubuntu 22.04 die letzte LTS-Version mit einer Qt 5-Basis. Anwender dürfte dies freuen, da KDE gegen Ende eines Releasezyklus meist die besten Produkte ausliefert, bevor man wieder von vorne anfängt. Kubuntu liefert ebenso Firefox als Snap aus und bleibt bei der Abkehr von KDEPIM zugunsten von Thunderbird.

Ubuntu MATE modernisiert leicht sein Design verglichen mit der Version 20.04. Dabei orientiert man sich am Yaru-Theme des Hauptderivats, das in das charakteristische Grün gefärbt wird. Ubuntu MATE unterscheidet sich hierdurch stark von anderen Distributionen, die MATE ausliefern. Auffällig ist die stärkere Bezugnahme auf GNOME-Programme wie Rhythmbox oder Shotwell. Firefox liegt noch nicht in der Snap-Version bei, aber vermutlich sind die Arbeiten hier nur noch nicht abgeschlossen, da Ubuntu MATE traditionell bereits Snaps ausliefert.

Wenig Neues zu berichten gibt es bei den Derivaten Xubuntu, Lubuntu und Ubuntu Budgie. Das liegt schlicht daran, dass die entsprechenden Desktopumgebungen kaum Veränderungen erfahren haben. Hier integriert man lediglich die neuen Versionen der Desktopumgebungen, welche so aber auch schon in beispielsweise 21.10 enthalten waren. Auffällig ist der vollständige Verzicht auf Snaps bei Xubuntu und Lubuntu. Ubuntu Budgie nutzt gegenwärtig Snaps nur Testweise für den Welcome-Screen.

Insgesamt hat die kommende Version 22.04 das Potenzial wieder ein stabiles und unaufgeregtes LTS-Release zu werden. Bei keinem Derivat sind momentan schwierige Strukturen oder potenziell problematische technische Umbrüche zu erwarten. Allerdings ist bis zum Feature Freeze noch ein wenig Zeit und somit kann das nur als erster Ausblick gewertet werden.

Der Artikel (x)Ubuntu 22.04 (Jammy Jellyfish) im Ausblick erschien zuerst auf [Mer]Curius

Programmiersprache: Rust 1.58 steht bereit

15. Januar 2022 um 22:21

Kurz notiert: Rust ist eine Programmiersprache, in der auch die Rendering-Engine Servo geschrieben wird, aus welcher Firefox-Innovationen wie Quantum CSS und WebRender stammen. Mittlerweile steht Rust 1.58 bereit.

Die Programmiersprache Rust wurde planmäßig in Version 1.58 veröffentlicht. Wer sich für alle Highlights der neuen Version interessiert, findet wie immer in der offiziellen Release-Ankündigung weitere Informationen.

Der Beitrag Programmiersprache: Rust 1.58 steht bereit erschien zuerst auf soeren-hentzschel.at.

KDE – Eine kleine Niedergangsgeschichte

15. Januar 2022 um 15:00
Von: Gerrit

Das Kool Desktop Environment war mal gestartet als Versuch „den“ Linux-Desktop zu erschaffen. Nach Jahren des schleichenden Niedergangs kann man sich nun hinter GNOME in der zweiten Reihe neben Xfce, MATE und anderen einreihen.

KDE konnte letztes Jahr sein 25-jähriges Jubiläum feiern und sieht sich natürlich selbst auf der Erfolgsspur. Das kann man auch anders sehen und wo, wenn nicht in diesem Blog, wo bekanntermaßen immer alles schlecht gemacht wird – vor allem Linux und hier insbesondere KDE und Debian – sollte man so eine Geschichte schreiben.

Bei der Recherche bin ich auf die Meldung zum 10-Jährigen Jubiläum von KDE gestoßen. Das deckt sich fast mit meinem persönlichen Linux-Einstieg, deshalb lassen wir diese Geschichte 2006 beginnen.

Wir schreiben das Jahr 2006. Smartphones brauchen noch ein paar Jahre und Microsoft hat gerade mit Windows Vista ein richtiges Fiasko erlebt. Im Linux-Land wittert man Morgenluft und tatsächlich wechseln merkbar enttäuschte Windows-Nutzer ins Linux-Lager. Passenderweise hatte sich kurz zuvor ein ambitionierter Unternehmer namens Mark Shuttleworth aufgemacht, eine Linux-Distribution zu erschaffen, die für normale Anwender benutzbar sein soll. Leider mit GNOME und hier gehts los.

Im Jahr 2006 gibt es im wesentlichen drei Linux-Desktops. KDE, GNOME und für Anwender mit geringeren Ressourcen und Anforderungen Xfce. Dazu natürlich noch eine Menge Windowmanager und andere Lösungen, aber die machen zusammen nicht nennenswert Marktanteile aus. GNOME und KDE haben sich bereits in den 1990ern parallel entwickelt, weil Qt nicht frei war und Alternativen schön sind. Mal so ganz stark verkürzt ausgedrückt.

2006 ist die Sache aber nicht entschieden. Die berühmten Desktopwars bestimmen die Diskussion und KDE und GNOME dürften in etwa gleich viele Nutzer auf sich vereinen. Es gibt regionale Schwerpunkte, auch abhängig von regionalen Schwerpunkten entsprechender Distributionen. KDE ist auf dem Höhepunkt des Entwicklungszweiges der Version 3.5. Bis heute eine der Versionen, an die sich viele Anwender gerne zurückerinnern. KDE ist so wichtig, dass Canonical nicht umhinkommt mit Version 6.06 KDE bzw. Kubuntu den gleichen Status wie dem Hauptderivat Ubuntu zuzusprechen und mit Jonathan Riddell einen Entwickler dafür hauptamtlich anzustellen.

Danach beginnt der Niedergang. Im Jahr 2008 veröffentlicht KDE die Version 4. Ein Debakel sondergleichen in der öffentlichen Wahrnehmung. Obwohl nur als Vorschauversion gedacht, kommuniziert man derart schlecht, dass der Ruf nachhaltig leidet. Denn die Software ist funktional nicht ausgereift und strotzt nur so vor Fehlern. Wohlmeinende Anwender bleiben bei 3.5, andere wenden sich enttäuscht ab.

Ewig können die Distributoren aber nicht an KDE 3.5 festhalten. In den Folgejahren stellen nach und nach die Distributionen um. Der Support von Kubuntu 8.04 endet beispielsweise bereits im Oktober 2009, weil Kubuntu angesichts der Entwicklung auf LTS-Support verzichten musste – gewissermaßen das erste KDE-Opfer, bei dem man hinter der offiziellen Hauptvariante zurückstecken musste. Nahezu zeitgleich erscheint openSUSE 11.2 ohne KDE 3.5. Die Nutze können nun nur noch migrieren, aber KDE SC 4 ist zu diesem Zeitpunkt immer noch von Alltagstauglichkeit weit entfernt. Entsprechend verschieben sich die Nutzerzahlen bei den Anwender und Distributionen.

Weil KDE es nicht hinbekommt, die Destopumgebung und die zugehörigen Programme ausreichend zu stabilisieren und die Nachfrage sinkt, ziehen die Distributoren Konsequenzen. War KDE bei SUSE Linux Enterprise bereits im Jahr 2009 mit Version 11 optional geworden, fliegt es in Version 12 im Jahr 2014 komplett aus der Distribution. 2012 degradiert Canonical Kubuntu zu einem normalen Derivat, in der Folge verlässt Jonathan Riddel Canonical. Mandriva und seine diversen Nachfolgelösungen als KDE-Hochburg gerät ebenso in Schwierigkeiten und verliert nachhaltig an Bedeutung. Zuletzt gab im Jahr 2018 Red Hat bekannt, dass KDE nicht mehr in der Enterprise-Distribution RHEL enthalten sein würde. Linux-Desktops im professionellen bzw. Enteprise-Umfeld sind nun durchweg GNOME-Desktops. Wer hätte das 2006 gedacht.

Die KDE-Entwickler sehen diese katastrophale Entwicklung. Man startet man eine beispiellose Kampagne, um die letzte Hochburg von KDE als Standarddesktop zu bewahren: openSUSE. Es gelingt KDE als Standarddesktop durchzudrücken. Ein kurzer Erfolg, denn nach einigen Umstrukturierungen hat openSUSE von vielen unbemerkt wieder den Verzicht auf einen Standarddesktop beschlossen.

Im Zuge der Querelen zwischen Kubuntu und Canonical kommt man 2016 auf die Idee, mit KDE neon eine eigene Distribution zu erschaffen. Die letzten verblieben Distributoren mit KDE-Schwerpunkt sind nachhaltig irritiert durch diese Aktion. Ein großer Erfolg wird KDE neon nicht, sondern dient eher als Anschauungsbeispiel für die aktuelle KDE-Version.

2022 gibt es keine verbreitete Distribution mit KDE als Standarddesktop. Wichtige Linux-Distributionen wie Debian, Ubuntu oder Fedora setzen standardmäßig auf GNOME oder haben von GNOME abgeleitete Alternativen entwickelt, wie z. B. Mint oder Pop OS!. KDE-Software spielt vor allem bei Rolling Release Distributionen noch eine nennenswerte Rolle und erfreut sich bei Arch Linux und Manjaro einiger Beliebtheit. Zudem kann es natürlich optional bei vielen Distributionen genutzt werden. Hiermit steht es aber auf einer ähnlichen Stufe wie die Xfce, MATE, LXQt und andere kleinere Lösungen.

Für einen solchen Niedergang gibt es keine einfachen Erklärungen. Dahinter stehen sicherlich auch Entwicklungen außerhalb der Reichweite der KDE-Entwickler und Verschiebungen im Distributonssegment. Aber einige Punkte kann man dennoch feststellen:

  • Schlechte Kommunikation der Entwicklung in Richtung der Distributionen und Anwender.
  • Auf Kritik reagierten die KDE-Entwickler mit einer Wagenburg-Mentalität.
  • Aus der Wagenburg-Mentalität folgte das konsequente Ignorieren der Bedarfe von stabilen Distributionen und vor allem der LTS-Distributionen, die von der Masse der Anwender genutzt werden. Das hat zu einer nachhaltigen Entfremdung zwischen Distributionen und KDE geführt.
  • Aus der Wagenburg-Mentalität folgte das konsequente Ignorieren der Anwenderbedarfe nach einer halbwegs stabilen, logisch zu bedienenden Desktopumgebung. Das hat nachhaltig Anwender vertrieben. Wir erinnern uns an fehlende Icons auf dem Desktop, eine Erdnuss in der Desktopecke, ein bis heute wackeliges KDEPIM. Irgendwann sind die KDE-Entwickler meist eingeknickt, nachdem der Kollateralschaden bereits gewaltig war. KDE ist immer noch damit beschäftigt Anwender zurück zu gewinnen, die man nach 2008 verloren hat.
  • Die KDE-Entwickler haben sehr oft lieber tolle Konzepte entwickelt als an Funktionen für die Anwender gedacht. Wir erinnern uns an aRts, Phonon, Nepomuk, Sonnet, Akonadi, KDE Frameworks.
  • Zig Umbennenung von KDE zu KDE SC zu KDE Plasma, von KDE zu KDE Applications zu nichts und zurück zu KDE Gear waren sicherlich nicht hilfreich für das Marketing.

Im Grunde genommen ist das schade, weil KDE Plasma gegenwärtig eine sehr stabil und funktional gut zu benutzende Desktopumgebung ist. Viele der Programme aus dem KDE-Umfeld sind funktional allen anderen Alternativen im Linux-Bereich überlegen. Sofern man von einer manchmal irrlichternden VDG und ihren Missetaten absieht, liefert KDE heute eine tolle Desktopumgebung aus und diese wird natürlich weiter eine Zukunft haben.

Aber Entwicklungen lassen sich nicht umkehren und KDE wird nicht mehr die Bedeutung von 2006 erreichen. Als man sich am Ende des 4er-Releasezyklus hinsichtlich Funktionen und Qualität gefangen hatte, waren die Distributoren als wichtige Mittler zwischen Upstream und den Nutzern bereits umgeschwenkt oder die Anwender hatten sich andere Distributionen gesucht. Einmal verlorene Marktanteile zurückzugewinnen, ist ein sehr hartes Unterfangen. Zu viele im Open Source-Segment unterschätzen dies.

Zu viele Fehler, zu viele schlechte Entscheidungen und ein auf GNOME ausgerichtetes Gesamtökosystem haben sich zementiert. KDE wird es weiter geben, das Projekt liefert gute Software. In einem Atemzug mit GNOME muss man es aber vermutlich nicht mehr nennen.

Der Artikel KDE – Eine kleine Niedergangsgeschichte erschien zuerst auf [Mer]Curius

Adblock auf DNS-Ebene – Keine Werbung in Apps und Webseiten

15. Januar 2022 um 12:52
Von: Gerrit

Werbung und Tracker zu blockieren ist eines der wichtigsten Elemente zum Schutz der digitalen Privatsphäre. Am Desktop reicht dafür oft ein Adblocker im Browser. Durch die vielen Apps muss man bei Android oder iOS anders vorgehen.

Vorbemerkungen

In der Vergangenheit hatte ich hier im Blog bereits zwei Lösungen vorgestellt: Blokada für Android und AdGuard Pro für das iPhone. Beide setzen auf ein virtuelles VPN, um den Datenverkehr des Geräts filtern zu können. Bei Lösungen halte ich auch immer noch für mögliche Vorgehensweisen. Es gibt noch zahlreiche weitere Apps, die vergleichbare Funktionen bieten. Sie funktionieren aber nicht in jeder Situation, z. B. wenn man aus anderen Gründen VPN benötigt.

Es gibt aber auch ernste Implikationen durch solche Blocker, die man in seiner Entscheidungsfindung berücksichtigen sollte. Dazu aus den FAQ von GrapheneOS:

Apps and web sites can detect that ad-blocking is being used and can determine what’s being blocked. This can be used as part of fingerprinting users. Using a widely used service like AdGuard with a standard block list is much less of an issue than a custom set of subscriptions / rules, but it still stands out compared to the default of not doing it.

GrapheneOS FAQ, abgerufen am 15.01.2022

Das ist beileibe keine Minderheitenmeinung, sondern so funktioniert im Prinzip auch der Tor Browser. Durch massive Maßnahmen zum Blockieren von Inhalten verstärkt man faktisch auch den eigenen Fingerabdruck. Beim Tor Browser versucht man stattdessen in der Masse unterzugehen und die Trackingmaßnahmen dadurch ins Leere laufen zu lassen.

Nur möchte ich wie viele andere eben auch trotzdem keine Werbung haben und dazu empfiehlt GraphenOS den Einsatz eines Private DNS (DNS-over-TLP) Server mit Unterstützung für Adblocking.

Funktionsweise von Adblock via DNS

Das Prinzip dieser Lösung ist ziemlich einfach erklärt. Webseiten oder Apps kontaktieren zur Auslieferung von Werbung die Adresse der Werbenetzwerke. Genau wie normale Anwender, wenn sie im Internet surfen, rufen die Apps keine konkrete IP-Adresse auf, sondern eine Domain. Diese Aufrufe von Drittanbietern kennen die meisten durch die Anzeige von Addons wie ublock origin im Browser.

Diese Domain muss in eine IP-Adresse übersetzt werden und dafür kommt der DNS-Server (Domain Name System) als „Telefonbuch des Internets“ zum Einsatz. Das ist ein normaler Vorgang und passiert immer, wenn wir im Netz unterwegs sind. Normalerweise sind bei jedem im Router die DNS-Server des Internetanbieters zur korrekten Weiterleitung hinterlegt. Dafür kann man aber auch individuelle Server hinterlegen.

Normalerweise sind solche DNS-Server neutral und verweisen auf die korrekte Ziel-IP. DNS-Server sind aber in manchen Ländern auch ein Instrument, um unerwünschte Netzinhalte zu blockieren, indem z. B. durch den Staat eine Blacklist gepflegt wird, die nicht aufgelöst werden darf. Ich schreibe dies deshalb, weil die Frage, ob man DNS-Server für so etwas wie Adblocking verwenden sollte, durchaus umstritten ist und es Leute gibt, die finden, solche Dienste sollten strikt neutral sein und die entsprechenden Funktionen sollten anderweitig umgesetzt werden.

Adblock via DNS-Server funktioniert, indem man einen DNS-Anbieter wählt, der eben keinen neutralen Server betreibt, sondern eine Blacklist mit eben jenen Servern verwaltet, die Werbung und/oder Tracker ausliefern.

Dadurch stellen die Webseiten oder Apps nicht fest, dass etwas blockiert wird, sondern bekommen die Rückmeldung, dass die gewählte Adresse nicht erreichbar ist. Ein Vorgang, der auch aus anderen Gründen zeitweilig passieren kann.

DNS-Server Anbieter mit Adblock-Funktion

Es gibt einige Betreiber entsprechender DNS-Server. Einen besonders wichtigen Anbieter listet GrapheneOS in seinen FAQ. Eine kleine Liste von DNS-over-TLS oder DNS-over-HTTPS Betreibern kann man im Privacy-Handbuch finden. Folgende drei Anbieter möchte ich hier explizit nennen:

  1. Mullvad DNS: adblock.doh.mullvad.net (Kommerzieller Anbieter, der einen sehr beliebten und positiv bewerteten VPN-Dienst betreibt. DNS-Server kann kostenlos genutzt werden)
  2. AdGuard DNS: dns.adguard.com/dns-query (AdGuard ist ein kommerzieller Anbieter, der sich durch den Verkauf von Apps und Addons im Bereich des Adblock finanziert. Der DNS-Server kann kostenlos genutzt werden)
  3. dnsforge: dnsforge.de/dns-query (privater Anbieter, der sich mit Spenden finanziert. Die Blocklisten kann man transparent auf der verlinkten Webseiten einsehen)

Die Wahl des Anbieters ist letztlich eine persönliche Entscheidung und ich kann und will hier keine fundierte Empfehlung abgeben. Neben den drei hier gelisteten und sicherlich sehr populären Servern, kann man auch andere im Privacy-Handbuch verlinkte DNS-Server-Anbieter wählen.

Android-Nutzer haben hier die volle Auswahl. Anwender mit einem iPhone sollten einen DNS-Server-Betreiber wählen, der DNS-over-TLS anbietet. Das wäre z. B. dnsforge.

Einrichtung

Grundsätzlich kann man einen DNS-Server individuell für jeden Browser und jedes Desktopbetriebssystem konfigurieren. Hier empfehle ich aber eher, den DNS-Server bei Bedarf zentral im Router auszutauschen oder ein Pi-Hole einzurichten (aber achtet dabei die Privatsphäre der anderen Nutzer im Netzwerk). Bei mobilen Geräten ist man natürlich nicht immer im heimischen Netzwerk oder mit diesem über VPN verbunden und hier kann es deshalb sinnvoll sein, zentral einen eigenen DNS-Server mit entsprechender Adblock-Funktion zu hinterlegen.

Einrichtung unter Android

Android macht es seinen Anwender wie so oft leicht, solche Funktionen zu nutzen. Das ist definitiv eine der Stärken des Betriebssystems von Google.

Man navigiert in den Einstellungen in den Bereich Netzwerke & Internet:

Hier kann man im Punkt Privates DNS einen individuellen DNS-Server hinterlegen:

Einrichtung und iOS (iPhone)

Apple macht das etwas anders. Hier gibt es für solche Konfigurationen (und auch andere Sachen) sogenannte Profile. Dabei handelt es sich um Konfigurationsdateien mit der Endung .mobileconfig Zur Verwendung muss man mittels Safari die Seite des entsprechenden Dienstanbieters aufrufen und dort das Profil herunterladen. Bei dnsforge sind diese prominent auf der Seite verlinkt. Mit einem Klick auf Zulassen aktiviert man das Profil. Anschließend kann man in den Einstellungen die geladenen Profile ansehen und aktivieren.

Funktion prüfen

Die korrekte Funktionsweise lässt sich mit verschiedenen Checkseiten prüfen. Mullvad bietet hierfür z. B. eine eigene Seite namens Mullvad-Check an. Eine andere Möglichkeit wäre dnsleaktest.

Grundsätzlich sollten jetzt in keiner App und auf keiner Webseite mehr Werbung angezeigt werden.

Grenzen der Methode

Ein Problem von Adblock via DNS ist die geringe Konfigurierbarkeit. Entweder man nutzt den Dienst oder nicht. Wenn man Probleme mit Overblocking hat oder den Datenverkehr überwachen und granularer steuern möchte, sollte man auf alternative Methoden setzen.

Das zentrale Aussperren von Werbung und Trackern über einen solchen Dienst ist aber eine sehr taugliche Lösung für all jene, die gerne einmal etwas einrichten und es dann vergessen wollen.

Der Artikel Adblock auf DNS-Ebene – Keine Werbung in Apps und Webseiten erschien zuerst auf [Mer]Curius

MangoPi MQ Pro – so groß wie Raspberry Pi Zero mit RISC-V CPU

15. Januar 2022 um 08:09
Von: jdo

Auch ein interessanter Ansatz. Ein Unternehmen namens MangoPi entwickelt derzeit einen Mini-Computer, der sich von der Größe mit dem Raspberry Pi Zero vergleichen lässt. Allerdings hat der MangoPi MQ Pro keinen ARM-basierten Prozessor, sondern eine RISC-V-CPU. Kaufen kannst Du das Gerät allerdings noch nicht. Es befindet sich noch in der Entwicklungsphase. Allerdings hat die Firma auf Twitter schon einige Bilder durchblitzen lassen. Damit können wir uns ungefähr vorstellen, was uns erwartet. Eine ungefähre Preisvorstellung habe ich auch noch nicht gefunden. […]

Der Beitrag MangoPi MQ Pro – so groß wie Raspberry Pi Zero mit RISC-V CPU ist von bitblokes.de.

Mozilla veröffentlicht Firefox 96.0.1

14. Januar 2022 um 18:18

Mozilla hat mit Firefox 96.0.1 ein Update außer der Reihe für seinen Desktop-Browser veröffentlicht.

Download Mozilla Firefox 96.0.1

Am gestrigen Morgen kam es zu einem zeitweisen Ausfall von Firefox für zahlreiche Nutzer. Grund hierfür war ein bereits länger existierender, aber bislang nicht bekannter Fehler in der HTTP/3-Implementierung von Firefox, der durch eine Konfigurationsänderung eines externen Hosting-Dienstleisters ausgelöst worden war. Da Mozilla diesen Dienstleister für das Load Balancing einer seiner Dienste nutzt, konnte das Problem bei potentiell jedem Nutzer auftreten, sobald Firefox eine Verbindung zu diesem hergestellt hat. Aber auch der Aufruf einer entsprechenden Website konnte das Problem auslösen, in dessen Folge Firefox in eine Endlosschleife geriet und nicht länger in der Lage war, Website-Anfragen zu beantworten.

Die Konfigurationsänderung des externen Dienstleisters wurde ca. eine Stunde nach der ersten Meldung bei Mozilla rückgängig gemacht, denn gestern um ca. 10.20 Uhr war das Problem genauso plötzlich wieder verschwunden, wie es gekommen war. Spätestens nach einem Neustart von Firefox funktionierte Mozillas Browser wieder für betroffene Nutzer.

Mit Firefox 96.0.1 hat Mozilla den Fehler im Firefox-Code behoben, der dieses Problem verursachte. An einer weiteren Verbesserung, damit Firefox selbst bei einem solchen Fehler nicht erneut in eine Endlosschleife gerät, arbeitet Mozilla bereits für ein kommendes Update.

Außerdem hat Mozilla mit Firefox 96.0.1 das Problem behoben, dass der Browser unter Windows bei Verwendung der Option, die Proxy-Einstellungen des Systems zu verwenden, die Ausnahmen nicht mehr berücksichtigte.

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

KDE-Nutzer bei Debian aufgepasst!

14. Januar 2022 um 09:15
Von: Gerrit

Debian verliert einen wichtigen Leistungsträger und ist daran nicht unschuldig. KDE-Nutzer sollten zur Kenntnis nehmen, dass sich Norbert Preining zurückzieht.

Debian hat Probleme. Nicht nur die Sicherheit, nicht nur in den verknöchterten Strukturen, es knirscht an vielen Stellen. Seit Jahren treten jedes Jahr Projektleiter an mit großen Agenden und nichts passiert. Die Strukturen, die das Projekt stabilisieren sollten, scheinen jede Bewegung zu verhindern, oft dienen sie nur noch der Blockade durch Minderheiten, die irgendetwas aufhalten wollen und dann in mühsamen Prozessen überstimmt werden müssen.

Norbert Preining ist seit einiger Zeit die Säule der Paketierung von KDE in Debian. Ohne ihn hätte man die aktuelle Stable-Version nicht mit halbwegs aktuellen KDE-Paketen ausgeliefert worden. Nun hat Norbert Preining seinen Rückzug angekündigt. Zwischen ihm und dem Debian-Projekt bzw. Menschen im Debian-Projekt knirscht es ja seit Längerem, deshalb musste er auch bereits in der Vergangenheit viel seiner Arbeit in OBS auslagern.

Der Verlust für Debian ist gewaltig. Die Liste der Pakete und die sachliche Analyse von Norbert Preining machen das deutlich. Einiges hat sicher eine Zukunft, aber vor allem für alles, was mit KDE zu tun hat und für Cinnamon in Debian sieht es nun düster aus. Norbert Preining legt zudem den Finger in eine Wunde, die viele ignorieren. Die vielen „Gruppen“ bei der Paketbetreuung sind oft nur eine Illusion und letztlich steht dahinter oft nur ein aktiver Betreuer – wie bei vielen „Teamarbeiten“ eben sonst auch.

Die Geschichte erinnert mich an Michael Stapelberg und seinen Rückzug aus Debian 2019. Dieser ist übrigens genau wie Norbert Preining zu Arch Linux gewechselt, aber das nur am Rande.

Debian brüstet sich immer mit seinen vielen Maintainern und Entwicklern, aber die Zahl der Leistungsträger im Desktop-Bereich ist überschaubar und große Weggänge gehen unweigerlich zulasten der Aktualität und Qualität. Darunter leiden übrigens auch abgeleitete Distributionen, wenn sie die Pakete nur übernehmen und die betroffenen Bereiche nicht selbst paketieren. Das Problem reicht deshalb über Debian hinaus.

Debian hat ein Problem, auch wenn nun wieder alle Debian-Nutzer standhaft leugnen und böse Kommentare im Stil von „Ach, der Gerrit mag Debian nicht“ schreiben werden. Vor allem Anwender von KDE Plasma und Cinnamon sollten die Entwicklung von Debian Testing im Auge behalten und sich mental darauf vorbereiten, beim nächsten Stable-Release eine neue Heimat zu suchen und bis dahin hoffen, dass nichts sicherheitsrelevantes für die Versionen in Stable passiert. Denn mir ist nicht klar, wer dort nun noch verantwortlich zeichnet.

Nachtrag 14.01.2022:

Nun hat auch Ferdinand bei Linuxnews berichtet, der ja ein guter Kenner der Debian-Gemeinschaft ist. Dort finden sich auch die Informationen zum Ablauf der Degradierung vor einiger Zeit und was für Mechanismen bei Debian hinter den Kulissen laufen.

Der Artikel KDE-Nutzer bei Debian aufgepasst! erschien zuerst auf [Mer]Curius

Ubuntu Desktop auf einem Raspberry Pi 4 2 GByte – Performance-Boost

14. Januar 2022 um 08:13
Von: jdo

Seit einigen Versionen kannst Du bekanntlich einen kompletten Ubuntu Desktop auf einem Raspberry Pi 4 oder 400 benutzen. Genauer gesagt gibt es eine offizielle Desktop-Version für Raspberry Pi seit Ubuntu 20.10 Groovy Gorilla. Allerdings lautet die Empfehlung mindestens 4 GByte RAM, weil sie der kleine Computer schon anstrengen muss. Pi-Fans wissen natürlich, dass die Server-Version auf früheren Varianten des Winzlings läuft. Für Ubuntu 22.04 LTS hat sich Canonical das Ziel gesetzt, das OS auch auf den Varianten mit 2 GByte […]

Der Beitrag Ubuntu Desktop auf einem Raspberry Pi 4 2 GByte – Performance-Boost ist von bitblokes.de.

SuperTux nun kostenlos via Steam verfügbar

14. Januar 2022 um 06:30
Von: jdo

Hast Du wie ich sowieso Steam auf Deiner Linux-Distribution installiert? Dann habe ich tolle Neuigkeiten. Ab sofort kannst Du das Spiel SuperTux kostenlos via Steam installieren. SuperTux ist ein 2D Platformer / Sidescroller, in dem Du als das Linux-Maskottchen Tux im Super-Mario-Stil durch die Landschaft hüpfst – genauer gesagt sind das Icy Island und Rooted Forest. Warum sich Tux das antut? Er will seine geliebte Penny aus den Händen ihres Kidnappers Nolok befreien! Was erwartet Dich bei SuperTux? Setzt schon […]

Der Beitrag SuperTux nun kostenlos via Steam verfügbar ist von bitblokes.de.

Open-Source-Saatgut-Stadt Dortmund

13. Januar 2022 um 21:35

Open-Source-Gärten in Dortmund

Die Open-Source-Tomate

Bild: Die Open-Source-Tomate

Die Stadt Dortmund wird Open-Source-Saatgut-Stadt! Inspiriert durch die Open Source Gardens sollen möglichst viele Dortmunder*innen Open-Source-Saatgut nutzen und untereinander als Community teilen. Das Umweltamt der Stadt Dortmund tritt hier als Impulsgeber zum Aufbau einer Open-Source-Saatgut-Community auf, welches die Koordination der Saatgutverteilung übernimmt. Das gemeinsame Dortmunder Gärtnern wird dieses Jahr mit einer Auftaktveranstaltung am 19.01.2022 begonnen. Die Stadt Dortmund stellt zum initiieren des Community-Kreislaufs Open-Source-Tomatensaatgut der Sorte Sunviva initial bereit. Zum Ende der Veranstaltung kann Interesse an dem freiem Saatgut bekundet werden.

Einen schönen Eindruck von der Sunviva-Tomate gibt es auf dem pixelfed-account von LUMA. Der Ansatz der Open-Source-Saatgut-Stadt folgt in dieser Pflanzsaison auf die Open-Source-Saatgutaktion der Kommunen für biologische Vielfalt e.V. vergangenen Jahres, bei der Open-Source-Saatgut als bundesweites Musterbeispiel für Biodiversität in verschiedenen Kommunen vorgestellt wurde. Mit Open-Source-Saatgut kann Offenheit gesät, Freiheit geerntet und leckeres Gemüse gegessen werden. Per Open-Source-Saatgutspende an die Shanti Leprahilfe aus Dortmund kann zusätzlich ein Beitrag zur Überlebenshilfe in Nepal geleistet werden. Hierzu kann die Shanti Leprahilfe kontaktiert werden.

Auf der Seite Saatgut wie Software – Eine Frage der Lizenz zeigt Do-FOSS die wesentlichen Gemeinsamkeiten von Saatgut und Software auf. In diesem Lichte freut es Do-FOSS besonders, dass das Dortmunder Engagement für Open-Source-Saatgut nun im Sinne einer Community-Building-Strategie verfolgt wird. Entsprechend bewirbt Do-FOSS die Auftaktveranstaltung gerne und wünscht der Open-Source-Saatgut-Stadt Dortmund viel Erfolg – auch über die Stadtgrenzen hinaus.

Pressemitteilung der Stadt Dortmund im Wortlaut

Culinaris - Saatugut für Lebensmittel

Bild: Culinaris – Saatugut für Lebensmittel

Säen für die Pflanzenvielfalt – Diskussion über Open-Source-Saatgut und Ausgabe von Tomaten-Saatgut

Lust gemeinsam zu gärtnern? Das Umweltamt, das Amt für Angelegenheiten des Oberbürgermeisters und des Rates der Stadt Dortmund, die zivilgesellschaftlichen Initiativen OpenSourceSeeds, der Dortmunder Ernährungsrat (in Gründung), sowie das Klimabündnis Dortmund laden zur gemeinsamen Open-Source-Tomatenaufzucht ein. Am 19. Januar 2022, von 19:00 Uhr bis 21:00 Uhr treffen sich alle Interessierten online. Um Anmeldung wird per E-Mail wird gebeten: cnaehle@stadtdo.de. Es wird dann eine Bestätigungsmail mit Einwahl-Link verschickt.

Die Etablierung der „Open-Source-Saatgut-Stadt-Dortmund“ wird das erste Vorhaben sein des neuen kommunalen Handlungsprogramms „Klima-Luft 2030“ aus dem Handlungsfeld „Landwirtschaft und Ernährung“. Am 19. Januar 2022 wartet ein spannendes Programm, an dessen Ende man sich für die gratis Ausgabe von Open-Source-Saatgut der Tomatensorte Sunviva melden kann. Dann steht der kommenden gemeinsamen Pflanzsaison nichts mehr entgegen!

Für einen thematischen Einstieg in die Hintergründe zu Open-Source-Saatgut eignet sich dieses Erklärvideo auf der Startseite von OpenSourceSeeds (1:43 Min.): https://opensourceseeds.org.

Das Programm am 19. Januar 2022 ab 19 Uhr:

1. „Begrüßung und Moderation“
Umweltamt, Christian Nähle, 10 Min.

2. „Vorstellung der Initiative OpenSourceSeeds“ (https://www.opensourceseeds.org)
Dr. Johannes Kotschi, 20 Min. Vortrag, 10 Min. Fragen

3. „Auf dem Weg zur lokalen Ernährungswende – Vorstellung des Ernährungsrates Dortmund (in Gründung)“
Amt für Angelegenheiten des Oberbürgermeisters und des Rates der Stadt Dortmund & Ernährungsrat Dortmund in Gründung, Alessa Heuser, 10 Min.

4. „Aus der Praxis – Open-Source-Gärtner Jörg Lüling“
Kurzvortrag aus der Praxis mit Fotos, 10 Min.

5. „Zwischenreflexion und Vorstellung des Exportprojekts Dortmunder Open-Source-Saatgut als Überlebenshilfe (durch die Shanti-Leprahilfe https://shanti-leprahilfe.de)“
Shanti Leprahilfe Dortmund e.V., Marianne Grosspietsch, 10 Min.

6. Öffentlichkeitsarbeit
per Dialog vorgestellt, u.a. Umweltamt, Christian Nähle, 5 Min.

7. Abschluss „Saatgut ist heilig“
Klimabündnis Dortmund, Friedrich Laker und moderativer Abschluss
Umweltamt, Christian Nähle, 10 Min.

Im Anschluss gibt es in einem Breakout-Raum ein ergänzendes Angebot für Lehrkräfte von Claudia Werner. Hierzu wird bereits auf den Open-Source-Saatgutblog der Johann-Gutenberg-Realschule verwiesen: https://www.jgr-dortmund.de/schulleben/projekt-open-source-tomate-sunviva.html)

Zum Hintergrund:

Klimawandel fordert Vielfalt im Saatgut

Der internationale Saatgutmarkt wird von immer weniger Unternehmen bestimmt. Da die Saatgutfirmen ihre Züchtungen immer stärker vereinheitlichen, geht die Pflanzenvielfalt stetig zurück. Diese Entwicklung verringert die Fähigkeit der Landwirtschaft, sich an regionale Unterschiede und den Klimawandel anzupassen und macht sie damit auch anfälliger für Umwelteinflüsse. Ökologische Vielfalt ist eine zentrale Grundlage dafür, dass sich Landwirtschaft an den Klimawandel anpassen kann. Dafür leistet das samenfeste Open-Source-Saatgut einen entscheidenden Beitrag zur Klimafolgenanpassung. Durch die aktuelle Entwicklung auf dem Saatgutmarkt ist nicht nur die ökologische Vielfalt, sondern auch unsere
Ernährung gefährdet.

Steriles Hybridsaatgut und seine Folgen für Landwirt*innen

Gemüse keimt heutzutage in der Regel von sogenanntem Hybridsaatgut. Für Hybridzüchtungen werden bestimmte Eigenschaften einer Pflanze wie Pflanzengröße, Form und Farbe der Früchte durch Kreuzung von Inzuchtlinien verstärkt. Ein gewünschter Effekt ist, dass die erste Generation überdurchschnittlich gute Ertragsergebnisse liefert. Die Kehrseite ist jedoch, dass die Landwirt*innen das Saatgut aus eigener Ernte nicht verwenden können. Es verliert seine Einheitlichkeit. Manche Pflanzen würden z.B. sehr groß, andere sehr klein. Das bringt enorme Schwierigkeiten für die Weiterverarbeitung und den Verkauf der Ernte mit sich. Zum Teil sind Hybride sogar steril, so dass sie sich gar nicht fortpflanzen können. Zudem dürfen Landwirt*innen das selbst geerntete Saatgut mitunter aufgrund von Lizenzbestimmungen nicht verwenden. Auf diese Weise entsteht neben der ökologischen Verringerung auch eine Abhängigkeit der Landwirt*innen von Saatgutproduzent*innen, denn das Saatgut muss jedes Jahr neu gekauft werden. Dies trifft sowohl die heimische Landwirtschaft als auch Landwirt*innen in Länden des Globalen Südens. Die Alternative zu Hybridsaatgut ist samenfestes Saatgut, das nachbaufähig, also fruchtbar ist und in den nächsten Generationen Pflanzen mit den gleichen Eigenschaften hervorbringt.

Berücksichtigung regionaler und klimatischer Unterschiede

Die in Dortmund auf dem Acker der Solidarischen Landwirtschaft Kümper Heide gesäte Tomatenpflanze „Sunviva“ ist samenfest. Sie ist aber nicht nur aufgrund ihrer Samenfestigkeit, sondern auch wegen ihrer rechtlichen Eigenschaften ein wesentlicher Baustein für die Klimafolgenanpassung. Denn nach ihrer Züchtung wurde die Tomatensorte unter eine Open-Source-Saatgutlizenz gestellt. Anders als bei herkömmlichen Rechten an Saatgut erlaubt diese Art der Lizenz, die Samen frei und kostenlos zu verwenden. Auf diese Weise wird die Verwendung des Saatguts für die Allgemeinheit gesichert. Die Besonderheit ist, dass Landwirt*innen das Saatgut vermehren und für regionale Bedürfnisse weiterentwickeln dürfen. Dabei bleibt es auch in Zukunft frei von Lizenzkosten. Anders als bei Einheitssaatgut großer globaler Konzerne können daher bei Open-Source-Saatgut regionale Unterschiede und klimatische Veränderungen bei der Züchtung und beim Anbau dauerhaft berücksichtigt werden.

Solidarische Landwirtschaft in Dortmund

Als Partnerin für den Anbau der Open-Source-Tomate „Sunviva“ hat sich die Solidarische Landwirtschaft (SoLaWi) Kümper Heide in Dortmund angeboten. Die Grundidee jeder SoLaWi ist, dass sich Landwirt*innen mit Verbraucher*innen von Anfang an in einer Gemeinschaft zusammentun. So verpflichten die Mitglieder sich im Vorfeld zur Abnahme des Gemüses und finanzieren alles, was für den Anbau notwendig ist, vor. Die Ernte steht allen gleichermaßen zur Verfügung. Somit werden Risiko und Ernte geteilt. Außerdem können alle Mitglieder der Gemeinschaft auf dem Acker mitarbeiten, sich in Arbeitsgruppen und demokratisch in ein Plenum einbringen. Ernährung wird als gemeinschaftliche Aufgabe wahrgenommen.

OpenSourceSeeds

Entscheidend für die erfolgreiche Arbeit des Umweltamtes ist die Bereitstellung einer Open-Source-Saatgut-Lizenz. Diese wurde 2017 durch „OpenSourceSeeds – AGRECOL“ https://www.opensourceseeds.org) zur freien Verfügung veröffentlicht.

Weitere Informationen

Für Rückfragen steht Ihnen in der Koordinierungsstelle für Klimaschutz und Klimaanpassung des Umweltamtes zur Verfügung:

Christian Nähle
(0231) 50–2 87 74
cnaehle@stadtdo.de
http://www.klimaschutz.dortmund.de

Die Stadt Dortmund unterstützt mit diesem Programm die UN-Ziele für Nachhaltige Entwicklung.

Redaktionshinweis:

Ergänzend hängt dieser Medieninformation die Pflanzanleitung an „Tomaten selbst zu ziehen ist gar nicht schwer“.

Außerdem ist ein Bild der Open-Source-Tomatensorte Sunviva beigefügt (Quelle: Culinaris – Saatugut für Lebensmittel).

Pressekontakt: Christian Schön

Gefördert durch mit ihrer mit Mitteln des
Logo Engagement Global Logo Servicestelle - Kommunen in der einen Welt Logo Bundesministerium für wirtschaftliche Zusammenarbeit und Entwicklung

Dokumente zum Herunterladen

Die Pressemitteilung der Stadt Dortmund vom 12.01.2022 kann hier und die Pflanzanleitung „Tomaten selbst zu ziehen ist gar nicht schwer“ kann hier heruntergeladen werden.

CC0
Soweit im gesetzlichen Rahmen möglich verzichtet der Autor auf alle Urheber- und damit verwandten Rechte an diesem Werk.
Es kann beliebig genutzt, kopiert, verändert und veröffentlicht werden.
Für weitere Informationen zur Lizenz, siehe hier.

The post Open-Source-Saatgut-Stadt Dortmund appeared first on Do-FOSS.

Lesetipp: Apple zwischen Datenschutz und Marketing

13. Januar 2022 um 20:02
Von: Gerrit

Apple hat seit vielen Jahren Datenschutz und Privatsphäre als Kundeninteresse und damit als lohnenswerte Marketingstrategie erkannt. Doch wie viel Substanz steckt eigentlich dahinter?

Ich habe mich hier im Blog bereits häufiger wohlwollend damit beschäftigt und bekomme dafür dann auch immer viel Kritik. Apple = kommerziell, geldgeil, proprietär – da scheint bei vielen die rationale Abwägung auszusetzen.

Dabei ist das gar nicht nur meine Position, deshalb möchte ich in dieser Frage auf einen längeren Artikel dazu bei Dr. Datenschutz verweisen.

Dort werden die positiven Entwicklungen wie die Anti-Tracking-Strategie und sinnvolle Funktionen bei den Apps abgewogen gegen das Messen mit zweierlei Maß, wenn es um eigene Dienste geht. Hinzu kommt der Firmensitz in den USA und der immanente Datenabfluss. In manchen Bereichen kann die Realität zudem nicht mit den Versprechen mithalten, dazu zählen die Voreinstellungen und die Qualität der Verschlüsselung bei vielen Diensten.

Das Fazit ist dann auch entsprechend differenziert. Apple hat zweifellos einen Sinn für Datenschutz und es spielt auch immer wieder eine Rolle, aber es wird nicht bis ins Letzte effizient umgesetzt – vor allem wenn es um die eigenen Dienste geht.

Mein Punkt ist dann halt oft folgender: Google hat noch nicht mal einen Sinn für Datenschutz und das spielt bei Google immer nur eine Rolle, wenn man irgendwo wieder Apple hinterher eilt. Deshalb: Im Zweifel Apple-Hardware kaufen. Im mobilen Bereich haben wir ja fast nur die Wahl zwischen diesen beiden Polen.

Der Artikel Lesetipp: Apple zwischen Datenschutz und Marketing erschien zuerst auf [Mer]Curius

Lesetipp: Fedora Silverblue im Praxiseinsatz

13. Januar 2022 um 19:45
Von: Gerrit

Fedora Silverblue gehört zu den ambitionierten und gleichermaßen umstrittenen Projekten im Linux-Ökosystem. Read-only Dateisysteme, Flatpak, Container – alles dabei für einen kräftigen Shitstorm. Zum Glück gibt es auch rationalere Berichte.

Lennart Diener hat auf linuxnews zwei Artikel über seinen Langzeittest von Fedora Silverblue geschrieben:

Dabei kommt der Autor zu einem sehr differenzierten Bild. Das Problem sind – wenn man die ideologischen Scheuklappen ablegt – eher nicht die Flatpaks, sondern die mangelnde Stabilität der grafischen Paketmanager und die Notwendigkeit bei einem Update an der Betriebssystembasis immer neustarten zu müssen. Toolbox scheint zudem eine nette Idee zu sein, deren praktische Verwendung irgendwie noch nicht richtig klappt.

Ich empfehle beide Artikel. Viel davon kann ich nachvollziehen. Betriebssysteme mit Read-Only-Root-Dateisystem auf Basis von Ostree vertragen sich nicht so gut mit der Updatefrequenz von Fedora und die Oberfläche von GNOME ist halt wie sie ist.

Der Artikel Lesetipp: Fedora Silverblue im Praxiseinsatz erschien zuerst auf [Mer]Curius

Fisch, der sein Aquarium mit einem Raspberry Pi bewegen kann

13. Januar 2022 um 06:29
Von: jdo

Falls Du nun auf das Datum geschaut hast – nein, das ist nicht der 1. April. Wissenschaftler haben ein Aquarium gebaut, das ein Fisch selbst steuern kann. Dabei überwacht ein Raspberry Pi 3B+ die Bewegungen des Fisches und steuert dann entsprechend das Aquarium. Auf diese Weise hat der Fisch gelernt, wie er an Leckerlies kommt. Der Fisch startet dabei von verschiedenen Punkten im Raum und nur wenn er es zum markierten Bereich schafft, bekommt er eine Belohnung. Im kompletten Video […]

Der Beitrag Fisch, der sein Aquarium mit einem Raspberry Pi bewegen kann ist von bitblokes.de.

Thunderbird 91.5 veröffentlicht

12. Januar 2022 um 23:30

Die MZLA Technologies Corporation hat mit Thunderbird 91.5 ein planmäßige Update für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 91.5

Mit dem Update auf Thunderbird 91.5 hat die MZLA Technologies Corporation ein planmäßiges Update für seinen Open Source E-Mail-Client veröffentlicht und behebt damit aktuelle Sicherheitslücken. Darüber hinaus bringt das Update diverse Fehlerbehebungen der Versionsreihe 91, welche sich in den Release Notes (engl.) nachlesen lassen.

Der Beitrag Thunderbird 91.5 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Manjaro im Test – Rolling Release mit Sicherungsnetz

12. Januar 2022 um 20:34
Von: Gerrit

Manjaro ist im Rolling Release-Segment vielleicht das, was bei den stabilen Distributionen Linux Mint ist. Der Anspruch ist eine einfach zu verwendende, nutzerfreundlichen Distribution, selbst wenn es mal ideologisch oder konzeptionell nicht ganz sauber ist. Höchste Zeit für einen Test.

Einordnung

Manjaro ist eine sehr beliebte Distribution. Seit sie vor knapp 10 Jahren aus der Taufe gehoben wurde, hat sie immer mehr Anhänger gewonnen und es sieht nicht so aus, als ob sich das schnell ändern wird. Denn diese Beliebtheit hat Gründe, wie sich zeigen wird.

Manjaro ist ein Abkömmling von Arch Linux. Im Grunde genommen nehmen die Manjaro-Entwickler die Arch-Paketquellen und fügen einige eigene Pakete und Metapakete hinzu. Hinzu kommt eine Installationsroutine und eigene Live-Medien. Das Ganze wird dann ein wenig entschleunigt, denn während bei Arch mitunter mehrmals täglich Updates kommen, verfolgt Manjaro – ähnliche wie beispielsweise openSUSE Tumbleweed – ein Snapshot-Modell, bei dem Updates immer in einem größeren Schwung alle paar Tage/Wochen an den Anwender weiter gegeben werden. Idealerweise dann schon ein bisschen besser getestet als bei Arch, wo – wenn auch selten – mal ein kleiner oder größerer Fehler bei den hochfrequenten Updates erfolgen kann.

Arch-Nutzer sagen gerne, dass niemand Manjaro bräuchte, weil man alles mit Arch selbst erledigen könnte. So wie auch Ubuntu-Anhänger behaupten, niemand bräuchte Linux Mint und Debian-Anhänger finden gerne, dass sowieso alle Derivate von Debian überflüssig seien. Das ist eine ewige Diskussion. Letztlich finden die Distributionen Anhänger und das hat Gründe.

Manjaro mit KDE Plasma im Test

Varianten und Installationsmedien

Die Manjaro-Entwickler unterstützen offiziell die drei Desktopumgebungen Xfce, KDE Plasma und GNOME. Hinzu kommt Community-Support von Budgie bis Sway. Leider ist die Pantheon Shell nicht dabei, obwohl sie mittlerweile in Arch Linux angekommen ist. Für den Test entschied ich mich deshalb für KDE Plasma.

Es gibt Live-/Installationsmedien für alle Desktopumgebungen. Jeweils aufgeteilt in eine vollständige und eine minimale Variante. Hierbei ist zu beachten, dass die minimale Variante keineswegs so minimal ist. Wer sich ein bisschen mit Linux auskennt und seine Programme überwiegend selbst zusammen stellen möchte, der sollte sich für die minimale Variante entscheiden.

Installation

Manjaro beherrscht kein Secure Boot. Das ist bedauerlich und verglichen mit anderen Distributionen schade. Es ist aber auch nicht überraschend, da Arch Linux dieses ebenso nicht unterstützt. Daher muss man – so noch nicht geschehen – in den UEFI-Einstellungen vor der Installation Secure Boot abschalten.

Anschließend bootet das Live-Medium. Hier kann man wie üblich erst die Distribution testen oder gleich installieren. Als Installationsroutine verwendet Manjaro Calamares. Dabei handelt es sich um eine distributionsübergreifend verfügbare Installationsroutine, die sich zunehmender Beliebtheit erfreut.

Ich finde Calamares etwas sparsam bei den Funktionen, aber man bekommt damit die Installation hin. Seit meinem letzten Test von Calamares bei KDE neon hat man die Verschlüsselung offenkundig verbessert, womit mein schlimmster Kritikpunkt ausgeräumt ist.

Bei der Installation wähle ich mein persönlich präferiertes Setup mit einer unverschlüsselten Boot-Partition und einer verschlüsselten Btrfs-Partition ohne weitere Trennung in Root und Home. Die unverschlüsselte Boot-Partition nutze ich, da bei einer verschlüsselten Boot-Partition die Entsperrung von GRUB bei meinen Notebooks sehr lange dauert und der Sicherheitsgewinn den Komfortverlust nicht ausgleicht.

Manjaro verlangt bei der Installation neben der obligatorischen Anlage eines Benutzers auch die Vergabe eines root-Kennworts. Damit sträubt man sich gegen den Trend. Nachdem Ubuntu lange Jahre mit seinem sudo-Konzept allein auf weiter Flur stand, haben sich zuletzt Debian und Fedora dem angeschlossen und bieten ebenfalls die Möglichkeit den root-Account zu deaktivieren.

Die Installation ist dann schnell erledigt.

Erster Eindruck

Nach einem Neustart begrüßt den Anwender KDE-Plasma in einem angepassten Design Namens „Breath“.

Die Entwickler der Desktopumgebungen hassen das ja bekanntermaßen und GNOME bekämpft dies inzwischen aktiv, aber ich mag das gerne. Ich finde es schön, wenn Distributionen versuchen, ein gemeinsames Corporate Design über alle Desktopumgebungen zu legen und den Anwendern vermitteln „Du benutzt nicht irgendeine Distribution mit KDE Plasma, sondern Manjaro“. Wenn es einem nicht gefällt, kann man es ja ändern.

Die Softwareauswahl ist dann gar nicht so minimal und leider auch etwas inkonsistent. Neben Plasma und den wichtigsten KDE-Tools ist auch Firefox dabei. Warum ich aber Okular und Evince vorinstalliert brauche, erschließt sich mir nicht. Ebenso ist unter der Haube einiges an Gerümpel. Dazu zähle ich die vorinstallierte Multilib-Umgebung (Lib32-Bibliotheken), die auf dem System gar nicht benötigt werden und einiges weiteres.

Bei der Gelegenheit fragte ich mich mal wieder, warum Arch eigentlich als schlankes System gilt. Natürlich hat ein Setup mit meiner gewohnten KDE-Umgebung bei Arch bzw. Manjaro nur knapp 1000 Pakete, während es bei openSUSE oder debianoiden Systemen eher >2000 sind. Das liegt aber nicht daran, dass openSUSE oder Debian „fetter“ wären, sondern daran, dass die Arch-Paketierung ziemlich grobschlächtig ist. So enthält z.B. das Paket firewalld auch gleich die GTK-GUI zur Konfiguration oder pinentry alle Oberflächen, was bei openSUSE und Debian in eigene Pakete ausgelagert ist. Arch ist also sogar ganz im Gegenteil eher ziemlich fett. Dafür kann aber natürlich Manjaro nichts und ist letztlich auch eine Frage der Gewohnheit.

Nichtsdestoweniger sollten Anwender nach der Installation erst einmal aufräumen, unnützes entfernen und vielleicht auch manches nachinstallieren. So setzt Manjaro nach der Installation immer noch auf X.org und der Anwender muss die Wayland-Session erst nachinstallieren und aktivieren. Am Ende hat man dann aber eine konsistente Arbeitsumgebung, auf der sich weiter aufbauen lässt.

Manjaro macht vieles anders

Manjaro macht vieles anderes. Das reicht von Kleinigkeiten bis zu einem Rollback-System für das Betriebssystem. Beginnen wir mit den Kleinigkeiten. Der Screenshot zeigt es schon: Manjaro verwendet standardmäßig nicht die Bash, sondern zsh mit einem hübschen, aber durchaus eigenwilligen Design.

Ebenso eigene Wege geht man bei den verfügbaren Programmen. In den Paketquellen findet sich auch so etwas wie SoftMaker Office oder Vivaldi. Hier steht Pragmatismus und gute Angebote für die Anwender über ideologischen Abwägungen.

Natürlich kann man Manjaro ebenso wie Arch komplett auf der Kommandozeile administrieren. Im Unterschied zu Arch bietet man den Anwendern aber grafische Konfigurationswerkzeuge. Diese integrieren sich bei KDE durchaus ansehnlich in die Systemeinstellungen als sogenannte KCM. Dazu gehört die Hardwarekonfiguration, die grafische Installation von verschiedenen Kerneln und die Verwaltung von Sprachpaketen.

Zusätzlich kann man noch nette grafische Paketmanager wie Octopi einsetzen, das im Gegensatz zum vorinstallierten Pamac eine Qt-Oberfläche hat und sich gut in KDE Plasma integriert. Mit ein wenig Nacharbeit entsteht so ein konsistenter Desktop mit guten grafischen Verwaltungstools.

Wirklich besonders ist an Manjaro aber der konsequente Einsatz von Timeshift. Das Ganze funktioniert Out-of-the-Box mit bei einem Brtrfs-Dateisystem-Layout. Das legt die Manjaro Installationsroutine gleich mit einem passenden Subvolume-Schema an:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=1F65-2EB8                            /boot/efi      vfat    umask=0077 0 2
UUID=2da043ef-a76c-4a18-8e2e-27969be465f4 /boot          xfs     defaults,noatime 0 2
/dev/mapper/luks-305fb0b6-ced0-403a-978c-1831b5d32f7e /              btrfs   subvol=/@,defaults,noatime,autodefrag,compress=zstd 0 0
/dev/mapper/luks-305fb0b6-ced0-403a-978c-1831b5d32f7e /home          btrfs   subvol=/@home,defaults,noatime,autodefrag,compress=zstd 0 0
/dev/mapper/luks-305fb0b6-ced0-403a-978c-1831b5d32f7e /var/cache     btrfs   subvol=/@cache,defaults,noatime,autodefrag,compress=zstd 0 0
/dev/mapper/luks-305fb0b6-ced0-403a-978c-1831b5d32f7e /var/log       btrfs   subvol=/@log,defaults,noatime,autodefrag,compress=zstd 0 0

Timeshift legt nun vollautomatisiert regelmäßige Schnappschüsse des Systems an. Das Home-Subvolume wird dabei ausgeklammert, kann aber optional ebenfalls einbezogen werden. Dabei nutzt Timeshift die in Btrfs integrierte Schnappschussfunktion.

Geht mal etwas schief, kann man in GRUB einfach einen älteren Schnappschuss booten. Das klappt auch bei einer verschlüsselten System-Partition mit unverschlüsselter Boot-Partition. Hier ist man sogar openSUSE voraus, wo das dort zum Einsatz kommende Snapper mit diesem Setup nicht zurechtkommt.

Probleme und Kritik

Vor allem im Bereich der Sicherheit gibt es einige problematische Bereiche. Das erste sind die Verzögerungen bei den Updates. Hier müsste man schauen, ob sicherheitsrelevante Aktualisierungen schneller durch gereicht werden als normale Updates, bei denen es letztlich egal ist, ob sie eine Woche früher oder später kommen.

Deutlich negativer fällt da das Fehlen vieler Sicherheitsmaßnahmen auf (die Spannbreite dessen habe ich hier mal dargestellt), die anderswo bereits Standard sind. Nicht nur verzichtet man auf eine vorinstallierte Firewall wie z. B. firewalld oder ufw (beides kann man natürlich nachinstallieren). Man installiert noch nicht mal konsequent ein Sicherheitsframework wie AppArmor. Dies wird nur bei der vollständigen und nicht bei der minimalen Installation eingerichtet. Angesichts der alles andere als minimalen Ausstattung der Minimal-Version in anderen Bereichen ist das unverständlich. Das ist ansonsten doch schon ziemlicher Standard und kommt von Debian bis openSUSE überall zum Einsatz. Hier sehe ich deutliches Verbesserungspotenzial, zumal AppArmor natürlich in den Paketquellen vorhanden ist und vom Anwender eingerichtet werden kann. Bei der Zielgruppe werden das nur leider zu wenige tun.

Zusammengefasst

Manjaro macht einen richtig guten Eindruck. Ich bin selten nach einem Distributionstest so positiv überrascht. Manjaro liefert ein sehr rundes Gesamtpaket aus und mit ein bisschen Nacharbeit bekommt man ein wirklich gutes Desktopsystem.

Ich bin mit Arch Linux nie wirklich warm geworden, was zu einem guten Teil auch an der Community lag, die ich als arrogant und überheblich wahrgenommen habe. Manjaro baut zwar auf bewährten Arch-Prinzipien auf, macht aber vieles anders, manches besser und wirkt sehr sympathisch.

Manjaro ist eine Distribution, die es geschafft hat in die engere Wahl dessen, was ich so an Linux-Distributionen berücksichtige, aufgenommen zu werden.


Nachtrag vom 15.01.2022:

Präzisierung der Passage zu AppArmor wegen Unterschiede bei der Installation mit minimaler und vollständiger Variante.

Der Artikel Manjaro im Test – Rolling Release mit Sicherungsnetz erschien zuerst auf [Mer]Curius

Tails 4.26 ist da – Du kannst ab sofort aktualisieren

12. Januar 2022 um 16:30
Von: jdo

Das Changelog von Tails 4.26 – The Amnesic Incognito Live System – ist ziemlich übersichtlich. Der Tor Browser wurde auf Version 11.0.4 aktualisiert. Startes Du den Tor Browser und die Tor-Verbindung steht nicht, öffnet sich ein kleiner Assistent. Er fragt, ob Du eine Tor-Verbindung aufbauen oder den Tor Browser trotzdem starten möchtest. Im offiziellen Changelog findest Du noch ein paar weitere Änderungen, die allerdings für Anwenderinnen und Anwender weniger relevant sind. Bekannte Probleme gibt es speziell für Tails 4.26 nicht. […]

Der Beitrag Tails 4.26 ist da – Du kannst ab sofort aktualisieren ist von bitblokes.de.

❌