Slimbook ist auf Linux kompatible Systeme spezialisierter Hersteller aus Spanien. In Kooperation mit KDE erscheint nun das KDE Slimbook Plasma VI im KDE-Design und AMD-Hardware. 8 Zen-4-Kerne gepaart mit RDNA-3-iGPU und im Vergleich zum Vorgänger gesteigerter KI-Performance in Form des Ryzen 7 8845HS bilden das Herzstück.
Ralf hat sich auf die Suche zu Musik über Freie Software und Freie Gesellschaft begeben. Viel hat er nicht gefunden. Wisst ihr mehr?
Stefan ist aus dem Urlaub zurück und nun bin ich dran. Ich werde ab morgen für rund zwei Wochen meinen Schreibtischsessel gegen den Fahrradsattel tauschen und die Niederlande unsicher machen.
Das Linux-Magazin feiert seinen 30. Geburtstag in der Ausgabe 10/2024 mit einem facettenreichen Rückblick und einer Mega-Archiv-DVD mit (fast) allen Artikeln von 1994 bis 2024.
Der 11. Teil einer Einführung in die Python3-Bibliothek Tkinter und der lange Weg zum perfekten GUI.
Canonical hat die Aktualisierung von Ubuntu 22.04 LTS auf 24.04 LTS vorerst wegen eines kritischen Fehlers im APT-Solver gestoppt. An der Behebung wird gearbeitet.
Erstmals nimmt der Telegram-Gründer Pawel Durow Stellung zu seiner Einvernehmung in Frankreich. Hier findet ihr seine übersetzte Äusserung.
Generell lautet ja meine Empfehlung, bei produktiven Servern niemals ein Distributions-Upgrade durchzuführen, als z.B. ohne Neuinstallation von Ubuntu 22.04 auf 24.04 umzustellen. Manchmal halte ich mich aber selbst nicht an diese Regel. Testobjekt war ein Server mit Apache, MySQL, PHP, Mail (Postfix, Dovecot, OpenDKIM) und Docker.
Natürlich gab es Schwierigkeiten …
Fairerweise muss ich zugeben, dass do-release-upgrade noch gar kein Server-Update auf Version 24.04 vorsieht. Das ist ein wenig überraschend, als Ubuntu 24.04.1 ja bereits freigegeben wurde. Normalerweise ist das der Zeitpunkt, ab dem do-release-upgrade funktionieren sollte. Ich habe das Upgrade mit do-release-upgrade -d erzwungen. Selbst schuld also.
Update: Canonical rät aktuell wegen APT-Problemen explizit davon ab, Upgrades von 22.04 auf 24.04 durchzuführen (siehe https://lists.ubuntu.com/archives/ubuntu-release/2024-September/006225.html).
Zuerst habe ich ein letztes Mal alle 22.04-Updates installiert (also apt update und apt full-upgrade) und den Server dann neu gestartet.
Danach habe ich ein Backup des in einer virtuellen Maschine laufenden Servers durchgeführt. Zur Not hätte ich aus der gesicherten Image-Datei problemlos den bisherigen Zustand des Servers wiederherstellen können. Das war aber zum Glück nicht notwendig.
Das Distributions-Upgrade habe ich dann mit do-release-upgrade -d eingeleitet, wobei -d für --devel-release steht und das Update erzwingt. Es dauerte ca. 1/4 Stunde und lief an sich überraschend flüssig durch. Ein paar Mal musste ich bestätigen, dass meine eigenen Konfigurationsdateien erhalten bleiben und nicht durch neue Konfigurationsdateien überschrieben werden sollten.
Der nachfolgende Reboot verursachte keine Probleme, ich konnte mich nach kurzer Zeit wieder mit SSH einloggen. So weit so gut!
Die statische Netzwerkkonfiguration meines Servers erfolgt durch /etc/netplan/01.yaml. Dort sind sechs Nameserver eingetragen, je drei für IPv4 und IPv6. Überraschenderweise funktioniert im aktualisierten 24.04-Server keine Namensauflösung mehr — ein wirklich grundlegendes Problem! ping google.com führt also zum Fehler, dass die IP-Adresse von google.com unbekannt sei.
Ein kurzer Blick auf resolv.conf zeigt, dass es sich dabei um einen Link auf eine gar nicht existierende Datei handelt.
Anmeldenls -l /etc/resolv.conf
/etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf (existiert nicht)
dpkg -l | grep resolve verrät, dass systemd-resolved nicht installiert ist. Sehr merkwürdig!
Abhilfe schafft die Installation dieses Pakets. Die Installation ist aber ohne DNS gar nicht so einfach! Ich musste zuerst /etc/resolv.conf löschen und dann einen Eintrag auf den Google-DNS dort speichern:
rm /etc/resolv.conf
echo "nameserver 8.8.8.8" > /etc/resolv.conf
apt install systemd-resolved
reboot
Nach einem Reboot läuft DNS. resolvectl listet jetzt meine in /etc/netplan/01.yaml aufgeführten Nameserver auf.
Nächstes Problem: Apache startet nicht. systemctl status apache2 verweist auf einen Fehler in einer Konfigurationsdatei von PHP 8.1. Aber Ubuntu 24.04 verwendet doch PHP 8.3. Was ist da passiert?
Ein Blick in /etc/apache2/mods-enabled zeigt, dass dort noch PHP 8.1 aktiviert ist. Abhilfe:
a2dismod php8.1
a2enmod php8.3
systemctl restart apache2
Apache und PHP laufen jetzt, aber ein Blick auf die Nextcloud-Statusseite zeigt, dass /etc/php/8.3/apache2/php.ini sehr konservative Einstellungen enthält. Nach memory_limit=1024M und ein paar weiteren Änderungen ist auch Nextcloud zufrieden.
Auf meinem 22.04-Server hatte ich DKIM aktiv (siehe auch https://kofler.info/dkim-konfiguration-fuer-postfix/). Nach dem Upgrade funktioniert die Signierung der Mails aber nicht mehr. Der Grund war einmal mehr trivial: Beim Upgrade sind die entsprechenden Pakete verloren gegangen. Abhilfe:
apt install opendkim opendkim-tools
Keines der Probleme war unüberwindbar. Überraschend war aber die triviale Natur der Fehler. Beim Upgrade verloren gegangene oder nicht installierte Pakete, keine Synchronisierung zwischen den installierten Paketen und den aktivien Apache-Modulen etc. Ich bleibe bei meinem Ratschlag: Wenn Ihnen Stabilität wichtig ist, vermeiden Sie Distributions-Upgrades. Ja, die Neuinstallation eines Servers verursacht mehr Arbeit, aber dafür können Sie den neuen Server in Ruhe ausprobieren und den Wechsel erst dann durchführen, wenn wirklich alles funktioniert. Bei einem Upgrade riskieren Sie Offline-Zeiten, deren Ausmaß im vorhinein schwer abzuschätzen ist.
Gerade ist privacyIDEA 3.10 erschienen. Als wesentliche Neuerungen von privacyIDEA 3.10 gelten die Offline-Nutzung von WebAuthn sowie die Erweiterung der Authentifizierungsoptionen mit PUSH-Token.
Das Debian-Archiv enthält aufgrund seiner Größe zu jedem Zeitpunkt Pakete, die veraltet oder schon länger unbetreut sind. Eine neue Initiative will hier Abhilfe schaffen.
Homeserver haben Konjunktur. Je mehr Dienste darauf installiert werden, desto mehr Sinn ergibt ein Dashboard. Homarr ist eins der besten, bietet gutes Design und kann mehrere Server verwalten.
Der Jahresbericht von KDE für das Jahr 2023 listet eine beeindruckende Fülle von Events und Aktivitäten auf. Neben der Organisation von Events wurden auch 2023 wieder einige Sprints abgehalten.
Ich habe euch bereits in separaten Beiträgen gezeigt, wie ihr Fractional Scaling und VRR unter Gnome aktiviert. Die beiden dort gezeigten Befehle deaktivieren aber die jeweils andere Funktion. Wenn ihr beide Optionen gleichzeitig aktivieren...
Mein Erfahrungsbericht mit Libre Wokspace. Wie einfach war meine Installation auf einem Homeserver?
Firefox 130 verbessert die Übersetzungsfunktion, fügt weitere Sprachen hinzu und führt mit Firefox Labs die Möglichkeit zum Testen experimenteller Funktionen ein.
Der Virutal Private Server (VPS), welcher diesen Blog ausliefert, war heute in der Zeit zwischen 08:06 Uhr und 17:52 Uhr nicht erreichbar.
Ursache ist eine Störung im Nürnberger Rechenzentrum meines Anbieters Contabo. Die Störung besteht offenbar schon seit dem 30.08. (siehe Screenhot der Meldung unten), betraf meinen VPS aber erst heute.
Die Störung bei Contabo ist noch nicht behoben. Es ist nicht auszuschließen, dass dieser Blog nocheinmal davon betroffen sein wird. Ich bitte in diesem Fall um etwas Geduld.
Contabo hat einen Blog zur Aufarbeitung der Störung vom 2. September 2024 veröffentlicht. Die URL lautet: https://contabo.com/blog/nuremberg-incident-root-cause-analysis/
Tausende Server, hunderte verschiedene Dienste aber ein gemeinsames Zeichen für das gesamte Netzwerk?
Eine neue Idee macht im Fediverse die Runde und könnte Anwendungsfälle lösen, an denen das bereits bekannte Pentagram-Symbol für das Fediverse bisher scheiterte.
Updates von einer Ubuntu-LTS-Version auf die nächste waren noch nie problemlos. Auch dieses Mal häufen sich Berichte von Anwendern, bei denen die Aktualisierung schiefgegangen ist.
Die Tools für ein Dateisystem enthalten die nötigen Werkzeuge, um ein Dateisystem zu pflegen und zu reparieren. Die Tools für Bcachefs sind in Debian Stable derzeit nicht mehr verfügbar.
In diesem Beitrag erkläre ich kurz, was Ansible Lint ist und demonstriere dessen Anwendung am Beispiel meiner Ansible Collection tronde/nextcloud.
Er richtet sich primär an Personen, die mit Ansible Lint noch nicht vertraut sind. Linting-Profis werden vermutlich keine neuen Erkenntnisse gewinnen.
Lint (englisch für „Fussel“) ist eine Software zur statischen Code-Analyse. Davon abgeleitet hat sich das Verb linten (englisch to lint) für das Durchführen der statischen Code-Analyse etabliert.
https://de.wikipedia.org/wiki/Lint_(Programmierwerkzeug)
Dem obigen Zitat und der Projektdokumentation folgend, ist Ansible Lint dementsprechend ein Werkzeug zur statischen Code-Analyse von Ansible Playbooks, Roles und Collections. Mit der Anwendung dieses Werkzeugs auf die eigenen Ansible-Inhalte kann sichergestellt werden, dass diese gängigen Konventionen und Standards entsprechen.
Die Dokumentation beschreibt verschiedene Installationsverfahren. Ich habe ansible-lint als Bestandteil der Ansible Development Tools (ADT) installiert. Dies ist ein Werkzeugkasten mit weiteren Programmen wie z.B. `ansible-core` und Ansible Molecule, welche ich für die Entwicklung meiner Ansible Collection nutze.
Auf meiner Fedora Workstation habe ich die ADT wie folgt installiert:
~]$ mkdir venv
~]$ cd venv
venv]$ ]$ python -m venv adt
venv]$ source adt/bin/activate
(adt) venv]$ pip install pip --upgrade
Requirement already satisfied: pip in ./adt/lib64/python3.12/site-packages (23.3.2)
Collecting pip
Using cached pip-24.2-py3-none-any.whl.metadata (3.6 kB)
Using cached pip-24.2-py3-none-any.whl (1.8 MB)
Installing collected packages: pip
Attempting uninstall: pip
Found existing installation: pip 23.3.2
Uninstalling pip-23.3.2:
Successfully uninstalled pip-23.3.2
Successfully installed pip-24.2
(adt) venv]$ pip install ansible-dev-tools
Collecting ansible-dev-tools
Using cached ansible_dev_tools-24.7.2-py3-none-any.whl.metadata (11 kB)
… Ausgabe gekürzt
(adt) venv]$ adt --version
ansible-builder 3.1.0
ansible-core 2.17.3
ansible-creator 24.7.1
ansible-dev-environment 24.7.0
ansible-dev-tools 24.7.2
ansible-lint 24.7.0
ansible-navigator 24.8.0
ansible-sign 0.1.1
molecule 24.8.0
pytest-ansible 24.8.0
tox-ansible 24.8.0Ansible Lint liefert eine ganze Reihe von Profilen mit, welche Autoren unterstützen, die Code-Qualität schrittweise zu verbessern. Der Befehl ansible-lint --list-profiles gibt die verfügbaren Profile mit einer Beschreibung aus.
Ich werde im Folgenden mit dem Profil shared arbeiten, welches für Autoren gedacht ist, die ihre Collection auf https://galaxy.ansible.com veröffentlichen möchten.
Bevor es zur Sache geht, wechsel ich in das Projektverzeichnis meiner Ansible Collection und erstelle einen neuen Branch, mit dem Befehl git checkout -b lint. Die in meinem Repo vorhandene Datei .ansible-lint-ignore lösche ich, da ich im folgenden alle Fehler und Regelverstöße sehen möchte. Zu Beginn stellt sich mein Arbeitsverzeichnis wie folgt dar:
(adt) nextcloud]$ git status
On branch lint
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
deleted: .ansible-lint-ignore
no changes added to commit (use "git add" and/or "git commit -a")Das Programm ansible-lint besitzt mit der Option --fix die Fähigkeit, Fehler automatisch zu korrigieren und auch YAML-Dateien neu zu formatieren. Der folgende Code-Block umfasst die gekürzte Ausgabe, wenn das Kommando ansible-lint --profile=shared --fix im Arbeitsverzeichnis ausgeführt wird.
(adt) nextcloud]$ ansible-lint --profile=shared --fix
WARNING Listing 37 violation(s) that are fatal
galaxy[no-changelog]: No changelog found. Please add a changelog file. Refer to the galaxy.md file for more info.
galaxy.yml:1
var-naming[pattern]: Variables names should match ^[a-z_][a-z0-9_]*$ regex. (NC_HTML) (vars: NC_HTML)
roles/backup_restore_nextcloud/defaults/main.yml:4
…
risky-file-permissions: File permissions unset or incorrect.
roles/backup_restore_nextcloud/tasks/main.yml:18 Task/Handler: Copy backup files to container host
no-changed-when: Commands should not change things if nothing needs doing.
roles/backup_restore_nextcloud/tasks/main.yml:40 Task/Handler: Import tarball contents into an existing podman volume
no-changed-when: Commands should not change things if nothing needs doing.
roles/backup_restore_nextcloud/tasks/main.yml:54 Task/Handler: Export podman volumes to tarballs
var-naming[pattern]: Variables names should match ^[a-z_][a-z0-9_]*$ regex. (MYSQL_DATABASE) (vars: MYSQL_DATABASE)
roles/deploy_nextcloud_with_mariadb_pod/defaults/main.yml:13
…
Read documentation for instructions on how to ignore specific rule violations.
Modified 6 files.
Rule Violation Summary
count tag profile rule associated tags
33 var-naming[pattern] basic idiom
1 risky-file-permissions safety unpredictability
1 galaxy[no-changelog] shared metadata
2 no-changed-when shared command-shell, idempotency
Failed: 37 failure(s), 0 warning(s) on 25 files. Profile 'shared' was required, but 'min' profile passed.Obige Ausgabe:
galaxy[no-changelog]: No changelog found. Please add a changelog file. Refer to the galaxy.md file for more info.risky-file-permissions: File permissions unset or incorrect.no-changed-when: Commands should not change things if nothing needs doing.var-naming[pattern]: Variables names should match ^[a-z_][a-z0-9_]*$ regex.ansible-lint Änderungen an 6 Dateien vorgenommen hatMit git diff verschaffe ich mir einen Überblick, welche Änderungen ansible-lint vorgenommen hat. Dies sind in meinem Fall:
Als Nächstes sehe ich mir die übrigen Fehler der Reihe nach an. Die Dokumentation beinhaltet eine Übersicht mit Beschreibungen der einzelnen Regeln. Dies ist nützlich, wenn der kurze Text in der Ausgabe von ansible-lint nicht ausreichend ist.
galaxy[no-changelog]: No changelog found. Please add a changelog file.Unter Galaxy: Changelog Details finden sich Hinweise, wie dieser Fehler zu beheben ist. Ich erstelle die leere Datei CHANGELOG.md im Wurzelverzeichnis meiner Collection und der Fehler ist abgestellt.
Natürlich werde ich diese Datei zukünftig nutzen, um die wichtigsten Änderungen zu dokumentieren. ;-)
risky-file-permissions: File permissions unset or incorrect.Auch hier habe ich kurz in der Dokumentation unter risky-file-permissions nachgesehen. Den Fehler habe ich abgestellt, indem ich den Parameter mode: 0600 zum Task hinzugefügt habe.
Dies war ein Flüchtigkeitsfehler, wie er häufig passieren kann, wenn man seinen Code nicht konsequent überprüft. Ohne den Dateimode explizit zu setzen, kann dies zu unvorhersehbaren bzw. überraschenden Verhalten führen.
no-changed-when: Commands should not change things if nothing needs doing.An zwei Stellen bin ich leider nicht herumgekommen, das ansible.builtin.command Modul zu verwenden, da kein natives Modul für diese Aufgabe existiert. Betrachtet man sich die beiden Tasks fällt auf, dass diese jedes Mal Daten verarbeiten werden. Sie sind nicht idempotent. Im Ergebnis können sie erfolgreich sein oder fehlschlagen, aber sie werden immer Daten verarbeiten und dadurch ändern.
41 - name: Import tarball contents into an existing podman volume
42 ansible.builtin.command:
43 cmd: |
44 podman volume import
45 {{ item }} {{ backup_restore_nextcloud_import_path }}/{{ item }}.tar
46 loop:
47 - "{{ NC_HTML }}"
48 - "{{ NC_APPS }}"
49 - "{{ NC_CONFIG }}"
50 - "{{ NC_DATA }}"
51 - "{{ MYSQL_DATA }}"
52
53 # I need to use the command module as the volume module lacks the functionality
54 # to export podman volumes.
55 - name: Export podman volumes to tarballs
56 ansible.builtin.command:
57 cmd: podman volume export {{ item }} --output {{ backup_restore_nextcloud_export_path }}/{{ item }}.tar
58 loop:
59 - "{{ NC_HTML }}"
60 - "{{ NC_APPS }}"
61 - "{{ NC_CONFIG }}"
62 - "{{ NC_DATA }}"
63 - "{{ MYSQL_DATA }}"
64 tags:
65 - never
66 - backupUm herauszufinden, wie ich ansible-lint zufriedenstellen kann, schaue ich wieder in der Doku unter no-changed-when nach. Nach der dortigen Beschreibung ist mein Fehler, dass ich den Rückgabewert des Kommandos nicht behandel. Daher registriere ich nun eine Variable je Task, die die Task-Ausgabe aufnimmt und prüfe den Rückgabewert. Ist der Rückgabewert gleich 0 wird der Task-Status auf changed gesetzt, ist der Rückgabewert ungleich 0 wird der Status entsprechend auf failed gesetzt. Das ganze sieht nun wie folgt aus:
41 - name: Import tarball contents into an existing podman volume
42 ansible.builtin.command:
43 cmd: |
44 podman volume import
45 {{ item }} {{ backup_restore_nextcloud_import_path }}/{{ item }}.tar
46 register: __import_tar_output
47 changed_when: __import_tar_output.rc == 0
48 failed_when: __import_tar_output.rc != 0
49 loop:
50 - "{{ NC_HTML }}"
51 - "{{ NC_APPS }}"
52 - "{{ NC_CONFIG }}"
53 - "{{ NC_DATA }}"
54 - "{{ MYSQL_DATA }}"
55
56 # I need to use the command module as the volume module lacks the functionality
57 # to export podman volumes.
58 - name: Export podman volumes to tarballs
59 ansible.builtin.command:
60 cmd: podman volume export {{ item }} --output {{ backup_restore_nextcloud_export_path }}/{{ item }}.tar
61 register: __import_tar_output
62 changed_when: __import_tar_output.rc == 0
63 failed_when: __import_tar_output.rc != 0
64 loop:
65 - "{{ NC_HTML }}"
66 - "{{ NC_APPS }}"
67 - "{{ NC_CONFIG }}"
68 - "{{ NC_DATA }}"
69 - "{{ MYSQL_DATA }}"
70 tags:
71 - never
72 - backupCollection-intern verwendete Variablen leite ich mit zwei Unterstrichen (‚_‘) ein, um mir zu verdeutlichen, dass diese nicht durch den Nutzer gesetzt werden und daher auch nicht im README.md oder defaults/main.yml dokumentiert sind.
var-naming[pattern]: Variables names should match ^[a-z_][a-z0-9_]*$ regex.Hier brauche ich nicht weiter nachzuschlagen. Ich verstoße gegen diese Regel, da ich meine Variablen-Namen großgeschrieben habe. Die Ausgabe von ansible-lint zeigt dies deutlich:
var-naming[pattern]: Variables names should match ^[a-z_][a-z0-9_]*$ regex. (NC_HTML) (vars: NC_HTML)
roles/backup_restore_nextcloud/defaults/main.yml:4Diese Meldungen lassen sich mit folgendem Bash-Einzeiler abstellen:
$ for text in $(cut -d':' -f 1 roles/deploy_nextcloud_with_mariadb_pod/defaults/main.yml | grep -v '^$\|^#\|---'); do find roles -type f -iname "*.yml" | xargs sed -i -e "s/$text/\L&/g"; doneAus verschiedenen Gründen hebe ich mir die Überarbeitung für später auf und nutze die Meldung, um zu demonstrieren, wie man ansible-lint dazu bringt, bestimmte Fehler zu ignorieren.
Um Regeln für ausgewählte Dateien zu ignorieren, spezifiziert man den jeweiligen Dateinamen und den Namen der Regel in der Datei .ansible-lint-ignore, welche im Wurzelverzeichnis der Collection erstellt wird:
nextcloud]$ cat .ansible-lint-ignore
roles/deploy_nextcloud_with_mariadb_pod/defaults/main.yml var-naming[pattern]
roles/backup_restore_nextcloud/defaults/main.yml var-naming[pattern]Damit habe ich alle Probleme, die im ersten Durchlauf von ansible-lint gefunden wurden, adressiert. Ein zweiter Durchlauf zeigt das Ergebnis meiner Arbeit:
(adt) nextcloud]$ ansible-lint --profile=shared
WARNING Listing 33 violation(s) marked as ignored, likely already known
var-naming[pattern]: Variables names should match ^[a-z_][a-z0-9_]*$ regex. (NC_HTML) (vars: NC_HTML) (warning) # ignored
roles/backup_restore_nextcloud/defaults/main.yml:4
…Ausgabe gekürzt
WARNING Listing 1 violation(s) that are fatal
yaml[octal-values]: Forbidden implicit octal value "0600"
roles/backup_restore_nextcloud/tasks/main.yml:22
Read documentation for instructions on how to ignore specific rule violations.
Rule Violation Summary
count tag profile rule associated tags
1 yaml[octal-values] basic formatting, yaml
Failed: 1 failure(s), 33 warning(s) on 27 files. Profile 'shared' was required, but 'min' profile passed.Die ignorierten Regelverstöße werden als Warnung weiterhin ausgegeben, nehmen jedoch keinen Einfluss auf die abschließende Bewertung. Dafür habe ich einen neuen Fehler (yaml[octal-values]) eingebaut. Nach dem aktuellen Regelwerk erfordern oktale Werte ein explizites Quoting, um als Strings verarbeitet zu werden.
Nachdem ich das Problem mit mode: '0600' behoben habe, endet ein weiterer Lauf von ansible-lint schlussendlich mit:
Passed: 0 failure(s), 33 warning(s) on 27 files. Profile 'shared' was required, but 'production' profile passed.Damit erfüllt meine Collection aktuell sogar die Anforderungen des nächst höheren Profils production; allerdings nur, weil ich einige Regeln bewusst ignoriere. Daher ist aktuell noch nicht sichergestellt, dass meine Collection tatsächlich bei einem Import auf Ansible Galaxy akzeptiert wird.
Ich persönlich führe ansible-lint gern in einem eigenständigen Schritt aus. Es besteht jedoch auch die Möglichkeit, dies in den verwendeten Editor, die genutzte IDE oder Molecule zu integrieren und bei Änderungen automatisch laufen zu lassen.
Ich freue mich, wenn euch dieser Artikel gefallen hat.
Gnome unterstützt seit Version 46 Variable refresh rate (VRR). Ich habe mir kürzlich einen neuen Monitor gekauft, welcher VRR unterstützt. VRR ist standardmäßig nicht unter Gnome aktiviert und muss per Terminal zuerst aktivieren werden....
Am Wochenende hat Debian seine stabile Veröffentlichung auf Version 12.7 angehoben. Gleichzeitig erhielt der Vorgänger eine letzte Aktualisierung auf Version 11.11.
Nicht immer lässt sich zeitnah über jede Neuigkeit rund um das freie Betriebssystem berichten, manche Ereignisse sind es aber dennoch wert, Erwähnung zu finden. In dieser Zusammenfassung überblickt die Redaktion alle wichtigen Meldungen aus der Linux-Welt der vorangegangenen Woche.
Interessanter Gegentrend: Während ich vor ziemlich genau einem Jahr über das zu der Zeit aktuellste Beispiel HashiCorp schrieb, wo eine Umstellung auf BSL-artige Lizenzen erfolgte, scheint es wohl auch einige Kandidaten zu geben, die wieder auf OSI-genehmigte Lizenzen umstellen. So verkündete Elastic am vergangenen Donnerstag, das sie wieder mit ihrer Suchmaschinensoftware Elasticsearch "Open Source" werden möchten, indem sie die AGPL als Lizenzoption aufnehmen.
Hier einmal der Hintergrund bis jetzt, so wie es auf mich als externen Beobachter wirkte: Open Source hat es im Zeitalter der Cloud recht schwer, wenn man damit Geld verdienen möchte (um z. B. die Entwicklung zu finanzieren!). Das verbreitete Standardmodell zur Monetarisierung war bisher, eine Software Open Source anzubieten und den Support oder das Hosting kostenpflichtig anzubieten. Aus Kundensicht bestellt man dann direkt bei dem Hersteller, der seine Software auch am besten verstehen sollte.
Cloud Provider haben dem Modell das Wasser abgegraben, da sie einfach die Open Source Software nehmen und auf ihrer Plattform deployen konnten – ohne einen Cent dem Projekt zahlen zu müssen. Teilweise wurde die Software erweitert, ohne, die Änderungen wieder veröffentlichen zu müssen (deswegen sind auch die MIT- und BSD-Lizenzen so beliebt). Aus Kundensicht kauft man zwar nicht mehr bei dem Hersteller ein, hat aber
Die Antwort vieler Projekte war es nun, die Lizenz so zu ändern, dass dieses Verhalten nicht mehr möglich ist, z. B. durch die Beschränkung von Konkurrenz-Hostingprodukten. Das verstößt allerdings gegen das Diskriminierungsverbot der OSI, nach dem die Verwendung von Produkten nicht durch die Lizenz beschränkt werden sollte (siehe auch das Good-Evil-Thema bei der JSON-Lizenz).
In der Konsequenz spalteten sich wie mit Open Search Elasticsearch-Forks ab, die weiterhin die offenen Lizenzen nutzen und durch Cloud Provider wie AWS direkt gepflegt wurden und werden. Wie Elasticsearch betont, sollen diese Projekte aber gleichzeitig auch einen eigenen Weg mit eigener Spezialisierung entwickelt haben. Die Community war natürlich aber auch verärgert, da die Software Elasticsearch nun nicht mehr als Free Open Source Software (FOSS) galt.
Elasticsearch plant nun die Wogen zu glätten, indem die AGPL als weitere Lizenz zur ELv2 und SSPL zusätzlich aufgenommen wird. Die Nutzer können also frei entscheiden, welche Lizenz sie nutzen wollen, da insbesondere im Geschäftskontext die AGPL juristisch gesehen als heikel eingeschätzt wird, wenn man das Produkt aus verschiedenen Komponenten zusammengebaut und nicht den gesamten Quelltext veröffentlichen möchte. FOSS-Nutzer und Distributionen haben allerdings wieder die Möglichkeit, die Software wiederaufzunehmen. So entspricht z. B. die AGPL den Debian Free Software Guidelines.
Ende gut, alles gut? Wenn es nach der Ankündigung von Elastic geht, ist das Team zufrieden mit der Entscheidung, wieder Open Source zu sein. Ob der Fork OpenSearch aufrecht erhalten wird oder schlussendlich in das Urprodukt einfließt, ist allerdings noch nicht gewiss und muss sich in der Zukunft zeigen. Vielleicht sind die Communities auch schon zu sehr divergiert, sodass es nun unterschiedliche Lösungen für unterschiedliche Anwendungsfälle gibt.
