Die MZLA Technologies Corporation hat vor kurzem Thunderbird 102 veröffentlicht. Die neue Version des Open Source E-Mail-Clients bringt wieder viele Neuerungen und sollte demnächst auch als automatisches Update für Nutzer von Thunderbird 91 veröffentlicht werden.

Neue Version zum Download verfügbar, Updates in Kürze

Thunderbird 102 steht seit wenigen Wochen zum Download bereit. Dieser Artikel erscheint bewusst erst jetzt, da ein Update auf Grund einiger weniger, aber dafür bedeutender Probleme noch nicht umgehend zu empfehlen war. Automatische Updates von Thunderbird 91 sind zu diesem Zeitpunkt noch nicht aktiv. Nach mittlerweile drei erschienenen Bugfix-Updates für Thunderbird 102 sollte eine Freischaltung des Updates für Nutzer von Thunderbird 91 nun aber nicht mehr lange auf sich warten lassen.

Neuerungen von Thunderbird 102

Neue Icons und anpassbare Seitenleiste

Die auffälligste Neuerung nach Start von Thunderbird sind natürlich die Änderungen des Designs. Zahlreiche Icons wurden erneuert, die in der Ordnerliste sind jetzt sogar bunt, und auf der linken Seite gibt es eine neue Seitenleiste, welche den Wechsel zwischen den verschiedenen Komponenten E-Mails, Adressbuch, Kalender, Aufgaben sowie Chat ermöglicht. Auch sogenannte MailExtensions können diese Leiste erweitern. Der Nutzer kann die Leiste auf Wunsch nicht nur ausblenden, auch die Farben sind durch den Nutzer beliebig anpassbar.

Und das stellt nur einen Vorgeschmack auf Thunderbird 114 im kommenden Jahr dar. Denn dann soll Thunderbird in ganz neuem Glanz erstrahlen und noch mehr Anpassungsmöglichkeiten erhalten.

Anpassbarer Nachrichtenkopf

Neue Möglichkeiten zur Anpassung ist auch das Schlagwort für den Nachrichtenkopf, welcher gleich mehrere Optionen zur Anpassung erhalten hat, darunter die Option, Buttons wie gehabt mit Icon und Text, nur mit Icon oder nur als Text darzustellen. Andere Optionen sind das Anzeigen eines Profilbilds für den Absender, die Vergrößerung der Betreff-Zeile, das Ausblenden der Beschriftungszeile sowie immer die vollständige Adresse des Absenders anzueigen. Außerdem kann jetzt auch über den Nachrichtenkopf die Markierung einer E-Mail mit Stern-Symbol vorgenommen werden.

Neues Adressbuch

Von Thunderbird-Nutzern seit vielen Jahren gewünscht, nun ist es endlich da: Ein neues Adressbuch. Das neue Adressbuch, welches nun in einem Tab statt in einems separaten Fenster öffnet, erscheint aufgeräumter und ist kompatibel mit der vCard-Spezifikation, dem Industrie-Standard zum Speichern von Kontakten. Dies ermöglicht den einfachen Import von Kontakten aus anderen Anwendungen, welche vCards exportieren können.

Neuer Assistent zum Importieren und Exportieren

Thunderbird beinhaltet einen neuen Assistenten zum Importieren und Exportieren von Konten, Nachrichten, Adressbüchern und Einstellungen, welcher nicht nur andere Thunderbird-Installationen, sondern auch andere E-Mail-Clients wie SeaMonkey, Outlook und Apple Mail sowie den Import aus einer von Thunderbird exportierten Zip-Datei unterstützt.

Chat versteht jetzt auch Matrix

Die Chat-Funktion unterstützt jetzt auch das offene und dezentralisierte Chat-Protokoll Matrix, welches sich immer größerer Beliebtheit erfreut.

Und noch sehr viel mehr…

Dies war nur eine kleine Auswahl der größen Highlights von Thunderbird 102. Darüber hinaus gab es noch zahlreiche weitere Neuerungen, Verbesserungen sowie Fehlerbehebungen, welche sich in den Release Notes (engl.) nachlesen lassen. Und natürlich wurden auch wieder diverse Sicherheitslücken geschlossen.

Die mittlerweile erschienenen Updates auf Thunderbird 102.0.1, Thunderbird 102.0.2 sowie Thunderbird 102.0.3 haben die größten Probleme seit Erscheinen von Thunderbird 102 behoben.

Der Beitrag Thunderbird 102 mit vielen Neuerungen veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Seit neuestem hat Gnome das "mit 2 Fingern =>Rechtsklick" Syndrom von MAC.

WTF.

Endeckt durch eine Neuinstallation von Debian Bullseye.

Bei den GUI Optionen wurde ich nicht fündig.

Dann eben mit dem Holzhammer:

gsettings set org.gnome.desktop.peripherals.touchpad click-method areas

Geht wieder... Puh.

gefunden hier: https://www.dell.com/support/kbdoc/de-de/000129850/ubuntu-rechtsklick-auf-das-touchpad-funktioniert-nach-der-installation-von-ubuntu-18-04-lts-nicht-mehr.

Edit: Doch

In den Tweaks, oder Optimierungen gibt es die Option im unteren Drittel.

Gnome 42.3 (Bookworm) habe jetzt nicht kontrollliert, ob das bei Bullseye auch ging.

Seit neuestem hat Gnome das "mit 2 Fingern =>Rechtsklick" Syndrom von MAC.

WTF.

Endeckt durch eine Neuinstallation von Debian Bullseye.

Bei den GUI Optionen wurde ich nicht fündig.

Dann eben mit dem Holzhammer:

gsettings set org.gnome.desktop.peripherals.touchpad click-method areas

Geht wieder... Puh.

gefunden hier: https://www.dell.com/support/kbdoc/de-de/000129850/ubuntu-rechtsklick-auf-das-touchpad-funktioniert-nach-der-installation-von-ubuntu-18-04-lts-nicht-mehr.

Edit: Doch

In den Tweaks, oder Optimierungen gibt es die Option im unteren Drittel.

Gnome 42.3 (Bookworm) habe jetzt nicht kontrollliert, ob das bei Bullseye auch ging.

Arbeitsspeicher ist physisch meist ja nur begrenzt verfügbar. Deswegen gibt es unter so gut wie jedem Betriebssystem einen Auslagerungsspeicher, auf den im Notfall zurückgegriffen werden kann.

Problem dabei: Der Auslagerungsspeicher liegt für gewöhnlich auf der Festplatte, d.h. er hat lange Zugriffszeiten und ist auch was Schreib-/Leserate angeht entsprechend langsam.

Unter Linux-basierten Betriebssystemen gibt es aber seit Jahren die Möglichkeit, den sogenannten Swap in komprimierter Form in den RAM zu verlegen. Mag sich eigenartig anhören, funktioniert aber erstaunlich gut. Ich habe das mittlerweile auf vielen sehr unterschiedlichen Geräten getestet (Raspberry Pi 3 & 4, meine Laptops, die Workstation, mehrere Server), bei denen ich regelmäßig an die Grenzen des physisch vorhandenen RAMs stoße, und kann es wirklich nur empfehlen. Die Systeme laufen damit deutlich besser.

Damit nicht die CPU zum Flaschenhals wird, braucht man allerdings auch schnelle Kompressionsverfahren. Hier haben sich die letzten Jahre drei herauskristallisiert, welche gute Kompressionsraten bei hoher Kompressionsgeschwindigkeit liefern: lz4, zstd, sowie lzo.

Unter Fedora ist das ganze sogar seit Version 33 Standard, und mit Version 34 gab's nochmal ein paar Verbesserungen.

Für Debian-basierte Systeme, und damit auch Ubuntu und Raspbian, muss man allerdings noch das Paket zram-tools nachinstallieren. Anschließend sollte man auch noch einen Blick in die Konfigurationsdatei unter /etc/default/zramswap werfen, und ggf. Parameter anpassen:

# Compression algorithm selection
# speed: lz4 > zstd > lzo
# compression: zstd > lzo > lz4
# This is not inclusive of all that is available in latest kernels
# See /sys/block/zram0/comp_algorithm (when zram module is loaded) to see
# what is currently set and available for your kernel[1]
# [1]  https://github.com/torvalds/linux/blob/master/Documentation/blockdev/zram.txt#L86
#ALGO=lz4

# Specifies the amount of RAM that should be used for zram
# based on a percentage the total amount of available memory
# This takes precedence and overrides SIZE below
PERCENT=50

# Specifies a static amount of RAM that should be used for
# the ZRAM devices, this is in MiB
#SIZE=256

# Specifies the priority for the swap devices, see swapon(2)
# for more details. Higher number = higher priority
# This should probably be higher than hdd/ssd swaps.
#PRIORITY=100

Nachdem ich mich wirklich viel zu lange mit dem Thema befasst habe, bin ich zum Schluss gekommen, dass die einzige Option, die ich wirklich explizit festlegen möchte, die Größe des verwendeten RAMs ist. Und den setze ich immer auf die Hälfte des verfügbaren Arbeitsspeichers, d.h. ich entferne wie oben bereits geschehen die Raute vor PERCENT=50.

Wer mag, kann sich gerne noch weiter in die einzelnen Kompressionsalgorithmen einlesen, Benchmarks durchführen, und um ein paar Nanosekunden mehr oder wenig kämpfen, aber letztendlich sind die Standardeinstellungen schon sehr gut.

Anschließend muss dann noch der entsprechende Service neu gestartet werden (systemctl restart zramswap.service), oder man führt alternativ einen Neustart durch.

Danach gibt's drei Möglichkeiten, mit je etwas unterschiedlicher Ausgabe, um zu prüfen, ob alles wie gewünscht funktioniert:

# free -h
               total        used        free      shared  buff/cache   available
Mem:           7.5Gi       1.4Gi       3.1Gi        77Mi       3.0Gi       5.8Gi
Swap:          3.7Gi          0B       3.7Gi

# swapon --show
NAME       TYPE      SIZE USED PRIO
/dev/zram0 partition 3.7G   0B  100

# zramctl
NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lz4           3.7G   4K   64B    4K       4 [SWAP]

Wie man sehen kann, beträgt der physisch verfügbare RAM bei mir 8 GB, und der Swap entsprechend 4GB.

Und damit wäre auch die Frage im Titel beantwortet: Doch, ich würde. Und irgendwie fühlt es sich schon so an, als hätte man hier mal eben etwas mehr RAM, mit einem kleinen, downloadbaren Paket, nachgerüstet.

Weiterführende Links:

• Wikipedia - zram
• In defence of swap: common misconceptions

Wenn man ein auf Debian basierendes System hat, irgendwas von Red Hat nutzt, oder möglicherweise Arch Linux einsetzt, sollte man sich mal das Paket needrestart ansehen. Bei den gängigen Distributionen ist es auch in den Paketquellen enthalten.

Nach einem Systemupdate kann es vorkommen, dass Services & Container noch die alte Version einer soeben aktualisierten Bibliothek nutzen. D.h. die laufenden Services profitieren noch nicht vom Update - und gerade bei Sicherheitsaktualisierungen kann das fatal sein.

Das Problem kann dann auf unterschiedliche Arten gelöst werden:

• Man startet das komplette System neu - ist zwar effektiv, aber ineffizient
• Man versucht selbst mittels lsof herauszufinden was an Services neugestartet werden muss - kann man machen, ist aber etwas tricky
• Oder man überlasst eben needrestart diese Aufgabe

Needrestart startet dabei aber nicht einfach willkürlich Services und Container neu, sondern überlasst dem*der Benutzer*in diese Entscheidung. Dafür wird alles, was neugestartet werden kann und soll, in einem hübschen Menü präsentiert:

Wenn man's nutzen möchte - was ich empfehle, da sehr praktisch - reicht übrigens eine Installation des Pakets aus. Über diverse Hooks hängt sich das Programm dann automatisch in die jeweilige Paketverwaltung rein, man muss also nichts weiter machen geschweige denn konfigurieren.

Kleine Ausnahme bzgl. „reicht übrigens eine Installation des Pakets aus“ gibt es: Wenn needrestart anstelle eines hübschen grafischen Menüs eher eine Liste wie diese anzeigt:

Dann fehlt dem Progrämmchen eine Abhängigkeit, namentlich das Paket dialog. Unter Ubuntu wird's mitinstalliert, unter RHEL/Fedora kann eine manuelle Installation nötig sein:

$ sudo dnf install dialog

Gleich danach sollte man aber auch hübsche Menüs bekommen.

Ich bin über einen LibreOffice-Bug gestolpert, der seit über zwei Jahren bekannt ist, und bisher nicht gefixt werden konnte: Bug 133296 - NEW: LibreOffice doesn't print emojis in PDF export.

Um's kurz zu machen: LibreOffice kann keine Emojis ausdrucken. Man kann ein noch so schönes Dokument erstellen, aber egal wie man's druckt (und ich habe echt alles ausprobiert) – die Emojis darauf fehlen.

Jetzt haben manche eine Hassbeziehung zu Emojis, andrerseits fallen da auch so Dinge wie die Regenbogenflagge rein, die ich kürzlich in einem meiner Texte brauchte. Und genau die hatte auf dem Ausdruck dann gefehlt.

Eine „schöne" Lösung exisitiert nicht wirklich. Man kann die Datei als *.docx abspeichern, und den Rest mit Microsoft Office erledigen. Man kann das Dokument aber auch in Google G Suite hochladen, und dort drucken.

Problem bei beiden Lösungen: Es verschiebt einem die komplette Formatierung (zumindest war's bei mir so), und auch die Schriftarten waren plötzlich ganz andere. Microsoft Office weigerte sich sogar die Regenbogenflagge farbig darzustellen, was ausgerechnet bei diesem Emoji ein bisschen problematisch ist.

Es gibt allerdings eine andere Lösung, die einigermaßen zufriedenstellend ist: Man kann nämlich:

1. In LibreOffice unter Datei → Senden → HTML-Dokument erzeugen das Dokument ins HTML-Format konvertieren
2. Das daraus resultierende bzw. sich öffnende HTML-Dokument abspeichern
3. Das gespeicherte Dokument in einem Browser öffnen (ich nehme dafür gerne Firefox)
4. Über die Entwicklertools ggf. kleinere Fehler korrigieren (wie bspw. Zeilenabstände, mir wurde bei jedem Absatz eine Zeile zu viel eingefügt)
5. Das Dokument über Drucken → Als PDF speichern als, nunja, PDF abspeichern
6. Sich freuen, dass das geklappt hat, und nun das PDF einfach ausdrucken, inklusive aller Emojis und was man sonst noch drin hat

Der Vorgang ist alles andere als optimal, und es wäre nicht schlecht, wenn man schon mal ein bisschen mit HTML gearbeitet hat. Nachdem ich das jetzt aber schon mehrere Male die letzten Wochen machen durfte, und ich keinen Zugang zu Microsoft Office habe, und die Google G Suite leider nicht ganz so meinen Erwartungen entspricht, ist das die bisher beste Lösung, die ich gefunden habe.

In diesem Artikel stelle ich euch meine Ansible-Rolle vsphere_provision_lab vor. Mit dieser ist es möglich, vordefinierte Labor-Umgebungen, bestehend aus virtuellen Maschinen (VMs), in einem VMware vSphere Cluster zu provisionieren.

Um dem Text folgen zu können, ist es hilfreich zu wissen, was eine Ansible-Rolle (engl.) ist und worum es sich bei VMware vSphere handelt.

Anwendungsfall

Zum Test von Ansible-Modulen, -Playbooks und -Rollen sowie neuer Shell-Skripte und Konfigurationsparameter benötige ich wiederholt Test- bzw. Labor-Umgebungen. Diese bestehen aus VMs, welche im Vergleich zum Provisionierungszeitpunkt möglichst wenig Änderungen aufweisen sollten.

Da die Konfiguration der Gast-Betriebssysteme durch einen Testlauf verändert wird, soll eine solche Labor-Umgebung nach einem Test möglichst schnell dekommissioniert und neu-provisioniert werden können.

Der Vorgang der Provisionierung und Dekommissionierung soll automatisiert erfolgen.

Voraussetzungen

Um die Ansible-Rolle vsphere_provision_lab nutzen zu können, benötigt man:

• Einen Ansible Control Node mit einer Ansible-Version >= 2.9
• Eine vCenter Server Appliance oder einen vCenter Server; getestet habe ich die Rolle mit Version 6.7 U3

Die Ansible-Rolle verwendet die Module vmware_guest und vmware_guest_disk aus der Collection community.vmware. Um diese nutzen zu können, muss auf dem Ansible Control Node Python in einer Version >= 2.6 und PyVmomi installiert sein.

Da die Rolle neue VMs aus Templates erstellt, müssen entsprechende vSphere Templates vorhanden sein.

Variablen

In diesem Abschnitt werden die Variablen dokumentiert, welche mit Werten zu belegen sind. Diese sind in defaults/main.yml definiert und können entsprechend der Variablen-Präzedenz überschrieben werden.

vCenter-Variablen

• vsphere_provision_lab_vc_hostname – Der FQDN für die vCenter Server Appliance.
• vsphere_provision_lab_vc_username – Ein Benutzeraccount mit der Berechtigung, neue VMs zu erstellen.
• vsphere_provision_lab_vc_password – Spezifiziert das Benutzer-Passwort.
• vsphere_provision_lab_vc_datacenter – Name des vSphere Datacenter in der Bestandsliste, das verwendet werden soll.
• vsphere_provision_lab_vc_cluster – Der zu verwendende vSphere Cluster aus der Bestandsliste.
• vsphere_provision_lab_vc_datastore – Name des Datenspeichers, in dem die VMDK-Datei(n) erstellt wird/werden.
• vsphere_provision_lab_vc_folder – Der vSphere Folder Name, in dem die VM erstellt wird. Der Wert kann zuvor mit dem Playbook find_vmware_guest_folder.yml ermittelt werden.

Ich empfehle, sensible Informationen wie z.B. Benutzername und Passwort in einer verschlüsselten Ansible-Vault-Datei zu speichern.

Dictionary zur Spezifikation der VMs

Namen und Parameter der zu erstellenden VMs werden in einem YAML-Dictionary gespeichert. Der folgende Code-Block zeigt ein Beispiel für ein solches Dictionary mit einem Eintrag:

  vm1:
    vm_template: rhel8-en
    vm_ram_mb: 1024
    vm_vcpu: 2
    vm_net: VLAN123
    vm_ip: 192.168.0.5
    vm_netmask: 255.255.255.0
    vm_gateway: 192.168.0.254
    vm_domain: sub.example.com
    vm_hostname: host2
    vm_dns_servers:
      - 192.168.0.2
      - 192.168.0.3
    vm_dns_suffix:
      - sub.example.com
      - sub2.example.com
      - sub3.example.com
    vm_second_hdd: true
    vm_second_hdd_size_gb: "10"
    vm_second_hdd_type: "thin"
    vm_second_hdd_datastore: "DS1"
    vm_scsi_controller: "1"
    vm_unit_number: "1"
    vm_scsi_type: 'paravirtual'

Aus dem obigen Dictionary wird eine VM mit den folgenden Parametern erstellt:

• vSphere-Template ‚rhel8-en‘ wird als Vorlage verwendet.
• Der VM werden 1 vCPU und 512 MB RAM zugewiesen.
• Die vNIC an das VM-Netz ‚VLAN123‘ angeschlossen.
• Die VM wird mit der IP 192.168.0.1/24 und dem Standardgateway 192.168.0.254 konfiguriert.
• Im Gast-Betriebssystem wird der Hostname ‚host1‘ konfiguriert.
• Es werden DNS-Server und DNS-Suffixe konfiguriert.
• Es wird eine zweite Festplatte für die VM erstellt.

Diesen Block kann man nun für weitere VMs wiederholen. Wird keine zweite HDD benötigt, setzt man vm_second_hdd auf false.

Beispiel-Playbook

---
- hosts: localhost
  connection: local
  gather_facts: no
  vars_files:
    - /path/to/vault-with-vcenter-creds.vars
    - roles/vsphere_provision_lab/vars/rhel-lab.yml
 
  roles:
    - vsphere_provision_lab

In diesem Beispiel werden die Variablen aus zwei Dateien geladen.

• /path/to/vault-with-vcenter-creds.vars ist eine Ansible-Vault-Datei, welche die Anmeldeinformationen für den vCenter Server beinhaltet.
• roles/vsphere_provision_lab/vars/rhel-lab.yml enthält das Dictionary mit den zu erstellenden VMs.

Wie kann man diese Rolle nutzen?

Die Rolle steht unter der Lizenz GPLv2-or-later und kann aus dem GitLab-Repo vsphere_provision_lab heruntergeladen bzw. das Repo geklont werden. Sie ist im Role Path der Ansible-Installation zu speichern. Anschließend kann man sich an folgendem Ablaufplan orientieren:

1. Im Vorfeld sollten IP-Adressen und FQDNs für die zu erstellenden VMs registriert werden. Dieser Punkt ist spezifisch für eure jeweilige Umgebung.
2. Die Variablen sind mit gültigen Werten zu belegen.
3. Die Rolle ist in ein Playbook einzubinden.
4. Und schon kann das Playbook ausgeführt werden.

Fazit

Die Ansible-Rolle vsphere_provision_lab ermöglicht es, Labor-Umgebungen, bestehend aus VMs, als YAML-Dictionary zu definieren und auf einem VMware vSphere Cluster zu provisionieren.

Damit eignet sie sich, um wiederholt eine Umgebung mit gleichen Ausgangsbedingungen zu schaffen. Gleichzeitig wird die Zeit für die Provisionierung verkürzt, da manuelle Schritte entfallen.

So richtig idempotent arbeitet das Modul vmware_guest allerdings nicht. Führe ich das Playbook ein zweites Mal aus, wird der Status „Changed“ zurückgegeben, obwohl die VMs bereits existieren. Die VMs selbst überstehen den zweiten Lauf auch unbeschadet, jedoch zeigt der vSphere Client, dass sie rekonfiguriert wurden. Das könnte ich mir noch genauer ansehen, um der Ursache auf die Schliche zu kommen.

Was haltet ihr davon? Findet ihr diese Role nützlich, oder bevorzugt ihr andere Wege zur Provisionierung eurer VMs auf vSphere?