Auf einen Blick

​Der erste Blick auf die neue Long-Term-Support-Version (LTS) von Ubuntu lässt vermuten, dass die Entwickler in den vergangenen zwei Jahren im Tiefschlaf gewesen sind. Doch der Schein trügt: Ubuntu 26.04 hat es in sich, auch wenn es rein optisch kaum Unterschiede zur Vorgängerversion 24.04 gibt.

​Ubuntu 26.04 LTS wird mit GNOME 50 und Linux-Kernel 7.0 ausgeliefert und setzt nativ ausschließlich auf den Display-Server Wayland. X11 ist damit endgültig Geschichte. Zwar könnten dadurch vereinzelt Legacy-Anwendungen den Dienst quittieren, doch für den Großteil der Nutzer wird dieser Übergang dank ausgereifter Kompatibilitätsschichten nahtlos verlaufen.

​Die wichtigsten Neuerungen

​Besonders hervorzuheben sind folgende Funktionen, die den Desktop-Alltag effizienter gestalten:

• ​Optimierte Energie-Modi: Die Energieverwaltung wurde deutlich verfeinert. Nutzer können nun noch einfacher zwischen den Profilen Leistung, Ausgeglichen und Energie sparen wählen, um die Akkulaufzeit oder die Systemperformance gezielt auf die aktuelle Aufgabe abzustimmen.
• Autostart-Management: Software kann nun direkt nach dem Systemstart automatisch ausgeführt werden. Besonders für Kiosk-Szenarien ist dies ein echter Gewinn: So lässt sich beispielsweise festlegen, dass direkt nach dem Booten automatisch der Browser im Vollbild startet.
• ​Individuelle Skalierung: Endlich lassen sich angeschlossene Monitore unabhängig voneinander skalieren – ein Segen für Setups mit unterschiedlichen Pixeldichten.
• ​Moderner Dokumentenbetrachter: PDFs können jetzt nativ mit Kommentaren, Texten und handschriftlichen Notizen versehen werden, was Drittanbieter-Tools für einfache Korrekturen überflüssig macht.
• ​System-Werkzeuge: Mit Sysprof (Benchmark-Tool) und Ressourcen (ein moderner, einsteigerfreundlicher Taskmanager) ziehen mächtige Analyse-Tools ein, die nicht nur schick aussehen, sondern auch intuitiv bedienbar sind.
• ​Neues Terminal (Ptyxis): Das neue Standard-Terminal speichert Bearbeitungsstände und erlaubt mehrere Sitzungen in einem einzigen Fenster.
• ​Sicherheitszentrum: Hier können App-Berechtigungen (ähnlich wie unter Android) nachträglich verwaltet, erteilt oder entzogen werden.
• Systempflege: Das Tool Anwendungen & Aktualisierungen weicht einer Verschlankung der Systemsteuerung. Während Einsteiger nun eine übersichtlichere Oberfläche im neuen App-Center (vormals Anwendungszentrum) vorfinden, werden komplexe Repository-Einstellungen künftig – wie bei Profis ohnehin üblich – direkt über das Terminal verwaltet.

​Das Upgrade

​Wichtig: Bevor man das Upgrade wagt, ist ein vollständiges Backup des Systems und der persönlichen Daten unabdingbar!

​Offiziell wird das Upgrade von älteren Versionen meist erst mit dem ersten Point-Release (26.04.1) angeboten. Ungeduldige können den Prozess jedoch vorab manuell erzwingen.

​Tipp: Während der Aktualisierung wird man oft gefragt, ob bestehende Konfigurationsdateien ersetzt werden sollen. Hierzu wählt man im Zweifel das Beibehalten der alten Dateien, um individuelle Anpassungen nicht zu verlieren.

sudo apt install ubuntu-release-upgrader-core

sudo do-release-upgrade -d

Fazit

​Nach dem ersten Reboot lohnt es sich, das Dash kurz aufzuräumen und verwaiste Icons zu entfernen. Ein kurzer Check der Paketquellen unter /etc/apt/sources.list.d stellt zudem sicher, dass alle Drittanbieter-Repositorys korrekt auf die neue Version umgestellt oder bei Bedarf modernisiert wurden.

​Nutzer von Ubuntu 24.04 werden sich sofort heimisch fühlen, da die gewohnte Bedienung trotz der vielen technischen Neuerungen unter der Haube erhalten bleibt. Das Upgrade lohnt sich besonders für User, die von der verbesserten Hardware-Unterstützung und den neuen Sicherheits-Features profitieren wollen.

Ubuntu 26.04 LTS wird fünf Jahre unterstützt – Ubuntu Pro erweitert den Support auf zehn Jahre.

Der Beitrag Upgrade auf Ubuntu 26.04 für Ungeduldige erschien zuerst auf intux.de.

Ein neuer adminForge Service kann ab sofort genutzt werden.

Das Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld. Unterstütze unsere Arbeit mit einer Spende und diskutiere in unserem Chat mit.

by adminForge.

Ein neuer adminForge Service kann ab sofort genutzt werden.

Euer adminForge Team

Das Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld. Unterstütze unsere Arbeit mit einer Spende und diskutiere in unserem Chat mit.

by adminForge.

Ein neuer adminForge Service kann ab sofort genutzt werden.

Euer adminForge Team

Das Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld. Unterstütze unsere Arbeit mit einer Spende und diskutiere in unserem Chat mit.

by adminForge.

Sicherheit für Linux-basierte Mobile-Devices und App-Umgebungen prüfen

Linux bildet die Grundlage für zahlreiche mobile Betriebssysteme und App-Umgebungen, darunter Android und eine wachsende Zahl spezialisierter Embedded-Plattformen. Wer Linux-Sicherheit prüfen möchte, steht vor einer komplexen Aufgabe: Der Kernel selbst, darüber liegende Middleware-Schichten, App-Laufzeitumgebungen und das Mobile-Device-Management greifen ineinander und schaffen ein breites Angriffspotenzial. Schwachstellen entstehen nicht nur im Code, sondern auch durch Fehlkonfigurationen, unsichere Kommunikationskanäle und mangelhafte Berechtigungskonzepte. Gerade in professionellen Umgebungen, in denen mobile Geräte sensible Unternehmensdaten verarbeiten, kann eine unentdeckte Lücke weitreichende Folgen haben. Dieser Artikel erläutert, welche Bereiche bei einer sicherheitstechnischen Prüfung Linux-basierter Mobilgeräte und App-Umgebungen besonders relevant sind, welche Methoden sich bewährt haben und worauf Sicherheitsteams bei der Planung und Durchführung achten sollten.

Die Angriffsfläche Linux-basierter mobiler Systeme verstehen

Kernel und Systemarchitektur als Ausgangspunkt

Der Linux-Kernel ist das Fundament jedes Android-Geräts und vieler spezialisierter mobiler Plattformen. Seine Sicherheitsmerkmale, darunter Mandatory Access Control (MAC) über SELinux oder AppArmor, Namespace-Isolation und Seccomp-Filter, bieten eine solide Basis. Dennoch entstehen Risiken, wenn Geräte mit veralteten Kernel-Versionen betrieben werden oder Hersteller eigene Patches einpflegen, ohne diese ausreichend zu testen.

Besonders kritisch sind Treiber-Schnittstellen: Proprietäre Hardwaretreiber werden häufig ohne denselben Qualitätssicherungsprozess entwickelt wie der mainline Kernel. Angreifer nutzen gezielt Schwachstellen in GPU-, Kamera- oder Modem-Treibern, um Privilegien zu eskalieren. Eine vollständige Sicherheitsprüfung muss daher auch diese Schicht einschließen.

Middleware, Laufzeitumgebungen und App-Isolation

Zwischen Kernel und Anwendung liegen Laufzeitumgebungen wie die Android Runtime (ART) sowie zahlreiche Systemdienste. Fehler in diesen Komponenten können dazu führen, dass Apps auf Ressourcen zugreifen, für die sie keine Berechtigung haben. Inter-Process-Communication-Mechanismen (IPC), etwa über Binder, sind ein klassisches Angriffsziel, da sie Schnittstellen zwischen privilegierten und unprivilegierten Prozessen schaffen.

App-Isolation funktioniert nur dann zuverlässig, wenn das Berechtigungsmodell konsequent umgesetzt wird. In der Praxis finden Sicherheitsteams regelmäßig Apps, die unnötig weitreichende Berechtigungen anfordern oder Systemschnittstellen nutzen, die eigentlich nur für Systemdienste vorgesehen sind.

Methoden zur Prüfung der Linux-Sicherheit in mobilen Umgebungen

Statische Analyse von App-Code und Konfigurationsdateien

Die statische Analyse untersucht App-Binaries, Konfigurationsdateien und Manifest-Dateien, ohne die Anwendung tatsächlich auszuführen. Dabei werden unter anderem folgende Aspekte geprüft:

• Hardcodierte Zugangsdaten oder API-Schlüssel im Quellcode
• Unsichere kryptografische Algorithmen oder veraltete Bibliotheken
• Fehlkonfigurierte Berechtigungen im Android-Manifest
• Exportierte Komponenten (Activities, Services, Broadcast Receiver), die ohne Authentifizierung erreichbar sind

Werkzeuge wie MobSF (Mobile Security Framework) automatisieren einen Teil dieser Analyse, ersetzen aber keine manuelle Prüfung durch erfahrene Tester.

Dynamische Analyse und Laufzeitinspektion

Bei der dynamischen Analyse wird die Anwendung in einer kontrollierten Umgebung ausgeführt. Netzwerkverkehr wird mitgeschnitten und auf unsichere Verbindungen, fehlende Zertifikatsprüfungen oder übermäßige Datenweitergabe untersucht. Laufzeitverhalten lässt sich mit Frameworks wie Frida instrumentieren, um Funktionen zu hooken, Verschlüsselungsroutinen zu inspizieren oder Sicherheitsmechanismen wie SSL-Pinning temporär zu umgehen.

Gerade in Linux-basierten Umgebungen ist die dynamische Analyse aufschlussreich, da viele Schwachstellen erst im Zusammenspiel verschiedener Systemkomponenten sichtbar werden. Root-Erkennungsmechanismen, Tamper-Protection und Debugger-Abwehr lassen sich hier ebenfalls auf ihre Wirksamkeit prüfen.

Penetrationstests auf Systemebene

Neben der App-Analyse umfasst eine vollständige Sicherheitsprüfung auch Tests auf Systemebene. Dabei werden Netzwerkdienste gescannt, offene Ports identifiziert und Exploits gegen bekannte Schwachstellen in Systemdiensten geprüft. Für Geräte, die in Unternehmensumgebungen eingesetzt werden, ist die Analyse des Mobile-Device-Managements (MDM) besonders relevant: Fehlkonfigurierte MDM-Profile können Geräterichtlinien aushebeln oder unberechtigten Zugriff auf verwaltete Ressourcen ermöglichen.

Wer den Sicherheitsstatus mobiler Anwendungen systematisch bewerten möchte, kann dafür einen strukturierten mobile App Pentest beauftragen, der App-Analyse, Systemprüfung und MDM-Bewertung kombiniert.

Typische Schwachstellen in Linux-basierten App-Umgebungen

Unsichere Datenspeicherung und Dateirechte

Einer der häufigsten Befunde bei der Prüfung mobiler Linux-Umgebungen ist die unsichere Datenspeicherung. Apps legen sensible Informationen in SharedPreferences, SQLite-Datenbanken oder einfachen Textdateien ab, ohne diese zu verschlüsseln. Auf gerooteten Geräten sind solche Daten für andere Prozesse lesbar. Dateiberechtigungen spielen dabei eine zentrale Rolle: world-readable Dateien oder Verzeichnisse mit zu offenen Rechten sind ein klassisches Einfallstor.

Darüber hinaus hinterlassen Apps häufig Spuren in temporären Dateien, Log-Ausgaben oder Cache-Verzeichnissen, die vertrauliche Daten enthalten. Ein sorgfältiger Test prüft systematisch alle Speicherorte, auf die eine App schreibt.

Schwachstellen in der Netzwerkkommunikation

Fehlende oder fehlerhafte Implementierungen von TLS sind in mobilen App-Umgebungen weit verbreitet. Besonders problematisch sind:

• Deaktivierte Zertifikatsprüfungen in Entwicklungsversionen, die versehentlich in Produktionsbuilds übernommen werden
• Fehlende Certificate-Pinning-Implementierungen bei sicherheitskritischen Apps
• Unverschlüsselte Kommunikation über HTTP für bestimmte Endpunkte
• Schwache oder selbst signierte Zertifikate in Unternehmensumgebungen

Linux-basierte Geräte sind hier nicht grundsätzlich unsicherer als andere Plattformen, aber die Vielfalt der eingesetzten Bibliotheken und Frameworks erhöht die Wahrscheinlichkeit inkonsistenter Implementierungen.

Privilege Escalation und Kernel-Exploits

Auf System- und Kernel-Ebene sind Privilege-Escalation-Angriffe besonders folgenreich. Angreifer, die eine App-Sandbox durchbrechen, können über ungepatchte Kernel-Schwachstellen Root-Rechte erlangen und damit sämtliche Sicherheitsmechanismen des Geräts aushebeln. SELinux-Policies, die zu permissiv konfiguriert sind, bieten dann keinen ausreichenden Schutz mehr.

Regelmäßige Kernel-Updates und die Prüfung aktiver SELinux-Kontexte sind grundlegende Maßnahmen, um dieses Risiko zu begrenzen.

Mobile-Device-Management und Linux-Sicherheit prüfen

MDM-Konfigurationen als Sicherheitsschicht

Mobile-Device-Management-Systeme verwalten Geräterichtlinien, App-Verteilung und Zugriffskontrolle in Unternehmensumgebungen. Sicherheitsteams, die Linux-Sicherheit prüfen, dürfen diesen Bereich nicht vernachlässigen: Ein schwach konfiguriertes MDM kann als Einstiegspunkt dienen oder den Schutz korrekt konfigurierter Geräte untergraben.

Typische Prüfpunkte bei MDM-Systemen sind die Durchsetzung von Passwortrichtlinien, die Verschlüsselung verwalteter Daten, die Kontrolle installierbarer Apps sowie die Möglichkeit zur Remote-Wipe-Funktion. Enrollment-Prozesse sollten gegen unbefugte Geräteanmeldungen abgesichert sein.

Geräte-Compliance und Sicherheitsrichtlinien

Neben der technischen Konfiguration ist die Durchsetzung von Compliance-Anforderungen relevant. Kann ein Gerät, das gerootet wurde oder eine veraltete Systemversion verwendet, weiterhin auf Unternehmensressourcen zugreifen? Sind Integritätsprüfungen wie Android Attestation in den Enrollment-Prozess integriert? Diese Fragen lassen sich nur durch eine kombinierte Prüfung aus technischer Analyse und Prozessbewertung beantworten.

Praktische Empfehlungen für Sicherheitsteams

Sicherheitsteams, die Linux-Sicherheit prüfen möchten, profitieren von einem strukturierten Vorgehen:

Zunächst sollte eine vollständige Inventarisierung aller eingesetzten mobilen Geräte, Betriebssysteme und App-Versionen erfolgen. Ohne diesen Überblick lassen sich Priorisierungen nicht sinnvoll treffen. Besonderes Augenmerk gilt dabei Geräten, die nicht mehr mit Sicherheitsupdates versorgt werden.

Im nächsten Schritt empfiehlt sich eine Bedrohungsmodellierung: Welche Daten verarbeiten die eingesetzten Apps? Welche Angreifer sind realistischerweise relevant? Diese Analyse bestimmt, welche Testtiefe und welche Methoden angemessen sind.

Die eigentliche technische Prüfung sollte statische und dynamische Analyse kombinieren und Systemebene sowie Netzwerkkommunikation einschließen. Ergebnisse sollten priorisiert und mit konkreten Maßnahmen verknüpft werden, damit Entwicklungs- und Betriebsteams direkt handeln können.

Schließlich ist Sicherheit kein einmaliges Projekt. Regelmäßige Wiederholungstests, idealerweise nach jedem größeren App-Release oder Systemupdate, stellen sicher, dass neu eingeführte Schwachstellen frühzeitig erkannt werden.

Häufig gestellte Fragen

Was umfasst die Prüfung der Linux-Sicherheit für mobile Geräte?

Die Prüfung der Linux-Sicherheit für mobile Geräte umfasst mehrere Ebenen: den Linux-Kernel und seine Konfiguration, Middleware und Systemdienste, App-Laufzeitumgebungen sowie die Netzwerkkommunikation. Hinzu kommen die Analyse von App-Code, die Bewertung von Datenspeicherpraktiken und die Prüfung des Mobile-Device-Managements. Eine vollständige Prüfung kombiniert statische Analyse, dynamisches Testen und manuelle Expertenprüfung.

Wie unterscheidet sich ein Linux-Sicherheitstest von einem Standard-Android-Pentest?

Android basiert auf Linux, aber ein Linux-fokussierter Sicherheitstest geht tiefer: Er berücksichtigt Kernel-Konfigurationen, SELinux-Policies, Treiber-Schnittstellen und systemnahe Dienste, die bei einem reinen App-Test häufig ausgeblendet bleiben. Besonders bei Embedded-Geräten oder Custom-Android-Builds ist diese erweiterte Perspektive entscheidend, da Hersteller oft eigene Anpassungen vornehmen, die neue Angriffsvektoren einführen.

Wie häufig sollte die Sicherheit Linux-basierter mobiler Systeme geprüft werden?

Eine vollständige Sicherheitsprüfung empfiehlt sich mindestens einmal jährlich sowie nach wesentlichen System- oder App-Updates. Bei sicherheitskritischen Anwendungen, etwa in der Gesundheitsversorgung oder im Finanzbereich, sind häufigere Tests und ein kontinuierliches Monitoring sinnvoll. Patch-Management und die Überwachung neu veröffentlichter Schwachstellen sollten unabhängig davon dauerhaft etabliert sein.

Der Beitrag Linux-Sicherheit prüfen: Mobile Devices & Apps erschien zuerst auf intux.de.

Ein neuer adminForge Service kann ab sofort genutzt werden.

Euer adminForge Team

Das Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld. Unterstütze unsere Arbeit mit einer Spende und diskutiere in unserem Chat mit.

by adminForge.

Der unter Apache-Lizenz 2.0 veröffentlichte KI-Bildgenerator Nucleus Image von Nucleus AI belegt Spitzenplätze in einschlägigen Benchmarks und arbeitet dabei noch extrem ressourcensparend.

In der LibreOffice Welt herrscht Unruhe. Das Membership Committee der Document Foundation hat auf einen Schlag alle Mitglieder aus dem Umfeld von Collabora ausgeschlossen. Betroffen sind mehr als dreißig Entwickler, darunter einige der wichtigsten Köpfe der gesamten Projektgeschichte. Der Schritt trifft auf eine ohnehin angespannte Lage. Viele Gründungsmitglieder haben die Stiftung bereits verlassen und die […]

Der Beitrag TDF und Collabora im Streit: Bruch in der LibreOffice Gemeinschaft erschien zuerst auf fosstopia.

Transparenzhinweis: Der Entwurf dieses Artikels wurde mithilfe der Mistral-KI Le Chat erstellt und von mir redigiert.

Versteckte CLI-Optionen: Warum Entwickler sie nutzen – und warum das umstritten ist

In der Welt der Open-Source-Software gibt es eine Praxis, die immer wieder für Diskussionen sorgt: das Verstecken von CLI-Optionen (Command Line Interface). Diese Optionen sind oft nicht in der offiziellen Dokumentation aufgeführt, werden aber dennoch im Code implementiert – sei es für Debugging-Zwecke, als Notlösung für spezielle Anwendungsfälle oder als „Geheimtipp“ für erfahrene Nutzer.

Ein Beispiel ist der Commit im xfsprogs-Projekt, der die Erstellung von XFS-Dateisystemen kleiner als 300 MB standardmäßig blockiert. Gleichzeitig wurde eine undokumentierte Option (--unsupported) eingeführt, um diese Beschränkung zu umgehen – allerdings ohne Hinweis in der Manpage mkfs.xfs(8) oder Hilfeausgabe.

Doch warum tun Entwickler das? Und welche Vor- und Nachteile hat diese Praxis für Nutzer, Maintainer und die Community?

Warum versteckte CLI-Optionen existieren

1. Flexibilität für Entwickler und Tester

• Debugging & Testing: Versteckte Optionen ermöglichen es Entwicklern, spezielle Testumgebungen zu simulieren oder Fehler zu reproduzieren, ohne die Stabilität der Software für Endnutzer zu gefährden.
• Beispiel: Im xfsprogs-Commit wird die 300-MB-Beschränkung für automatisierte Tests (fstests) deaktiviert, wenn bestimmte Umgebungsvariablen gesetzt sind. Das verhindert, dass Hunderte von Tests angepasst werden müssen.

2. Schnelle Lösungen für Nischenprobleme

• Manchmal gibt es seltene Anwendungsfälle, die so selten sind, dass eine offizielle Unterstützung nicht sinnvoll erscheint.
• Beispiel: Die Option --unsupported für mkfs.xfs, da diese im Normalbetrieb gefährliche Folgen, wie den Verlust von Leistung und Redundanz, haben können.

3. Vermeidung von Missbrauch

• Manche Optionen sind potenziell gefährlich (z. B. das Umgehen von Sicherheitsprüfungen). Durch das Verstecken sollen nur Nutzer mit entsprechendem Wissen darauf zugreifen.

Die Kehrseite der Medaille: Warum versteckte Optionen problematisch sind

1. Mangelnde Transparenz

• Open Source lebt von Transparenz und Gemeinschaft. Versteckte Optionen widersprechen diesem Prinzip: Nutzer wissen nicht, welche Möglichkeiten es gibt, und können die Software nicht voll ausschöpfen und damit nicht uneingeschränkt nutzen.
• Frage: Wenn eine Option (nur in seltenen Ausnahmefällen) nützlich ist, warum sollte sie nicht dokumentiert werden?

2. Wartungsaufwand und „Technical Debt“

• Undokumentierte Features werden schnell zu „Technical Debt“: Neue Entwickler kennen sie nicht, Nutzer stoßen zufällig darauf und die Optionen werden nie offiziell unterstützt, obwohl sie vielleicht weit verbreitet sind.
• Beispiel: Im Linux-Kernel gibt es zahlreiche obskure Kernel-Parameter, die nur in Mailinglisten oder alten Foren erwähnt werden.

3. Frustration für Nutzer

• Nutzer, die auf ein Problem stoßen, finden keine Lösung in der Dokumentation, obwohl diese vielleicht existiert. Das führt zu unnötigen Support-Anfragen oder Workarounds.
• Beispiel: „Für eigene Tests möchte ich XFS-Dateisysteme kleiner 300 MB erstellen. Bis ich die Option --unsupported im Quelltext gefunden habe, war mir dies nicht möglich, ohne eine veraltete Version von xfsprogs zu nutzen.“

Deine Meinung zählt: Sollten versteckte CLI-Optionen abgeschafft werden?

Die Diskussion um versteckte Optionen ist auch eine Frage der Philosophie: Sollte Open-Source-Software maximale Freiheit bieten – auch auf Kosten von Komplexität? Oder sollte sie benutzerfreundlich sein und nur offizielle, getestete Features anbieten?

Was denkst du?

• Hast du schon einmal von einer versteckten CLI-Option profitiert oder dich über das Fehlen einer Dokumentation geärgert?
• Sollten Projekte wie xfsprogs alle Optionen offenlegen, selbst wenn sie offiziell nicht unterstützt und im IT-Betrieb gefährlich sind?
• Oder ist es in Ordnung, wenn Entwickler „Hintertüren“ für spezielle Fälle einbauen?

Teile deine Erfahrung in den Kommentaren!

Geschäftsführer Alexander Pockrandt verlässt die doppelte Führungsspitze des Zentrums für Digitale Souveränität. Leonhard Kugler wird gemeinsam mit Pamela Krosta-Hardl die Geschäfte führen.

Per Mail und im Forum kamen immer mehr Hinweise auf verzögerte Push-Benachrichtigungen rein. Ich selbst habe es ebenfalls bemerkt und wollte nun einmal handeln.

1. Um eine IP-Sperre auszuschließen habe ich den MollySocket Dienst erstmal umgezogen auf einen anderen Server, es brachte keine Besserung.
2. Nach ein paar Anpassungen im NGINX sind die Warnungen im Log nicht verschwunden: WARN mollysocket::ws::websocket_connection] Did not receive the last keepalive: aborting.
3. Ein bisschen Recherche und KI-Chat brachten mir die Idee die MollySocket eigene Datenbank zu leeren und quasi bei Null anzufangen.
4. Ein Test wie im Forum beschrieben unter neuer Subdomain mit den gleichen Einstellungen brachte gute Ergebnisse, Push-Benachrichtigungen kamen wieder direkt an.

Was muss ich machen?

Die MollySocket-Datenbank habe ich jetzt resettet.

Es sollte automatisch gehen, aber zur Sicherheit scannt bitte den QR-Code neu ein: https://molly.adminforge.de

Was ist Molly und MollySocket?

Molly ist ein unabhängiger Signal-Fork für Android mit verbesserten Features.

MollySocket ermöglicht es, Signal-Benachrichtigungen über UnifiedPush zu erhalten.

Euer adminForge Team

Das Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld. Unterstütze unsere Arbeit mit einer Spende und diskutiere in unserem Chat mit.

by adminForge.

Wer meinem Blog folgt und, wie im Artikel „PHP 7.4 FPM auf PHP 8.1 FPM für Nextcloud“, die externe PHP-Quelle von https://deb.sury.org/ eingebaut hat und später der Anleitung „PHP 8.2 FPM für Nextcloud 28“ gefolgt ist, könnte noch auf PHP 8.2 FPM hängen geblieben sein. Da sich diese Version im Status Security fixes only befindet, ist ein Wechsel auf eine höhere Version absolut empfehlenswert. Diese PHP-Version lässt sich recht einfach auf PHP 8.4 FPM umstellen. Unter dem Raspberry Pi OS ist das mit wenigen Befehlen erledigt. In diesem Beitrag zeige ich kurz, wie man PHP 8.2 deaktiviert, PHP 8.4 installiert und Nextcloud anschließend mit der neuen Version betreibt.

Vor der Umstellung empfiehlt es sich, ein Backup der Installation und der Datenbank anzulegen. Außerdem sollte geprüft werden, ob die eingesetzten Apps bereits mit Nextcloud 33 und PHP 8.4 kompatibel sind.

Installierte PHP-Version prüfen

Das System sollte zunächst auf den aktuellen Stand gebracht werden:

sudo apt update && sudo apt upgrade

Jetzt prüfen, welche PHP-Version aktuell aktiv ist:

php -v

Falls Apache mit PHP-FPM genutzt wird, lohnt sich auch ein Blick auf die aktiven Module und Konfigurationen.

PHP 8.4 und benötigte Module installieren

Wer von PHP 8.2 auf PHP 8.4 wechselt, installiert zunächst die neue Version samt der für Nextcloud üblichen Erweiterungen:

sudo apt update

sudo apt install php8.4 php8.4-mbstring php8.4-gd php8.4-curl php8.4-imagick php8.4-intl php8.4-bcmath php8.4-gmp php8.4-mysql php8.4-zip php8.4-xml php8.4-apcu libapache2-mod-php8.4 php8.4-bz2 php8.4-redis

PHP 8.2 deaktivieren und PHP 8.4 aktivieren

Nun wird PHP 8.2 deaktiviert und PHP 8.4 aktiviert:

sudo update-alternatives --config php

sudo update-alternatives --config php
Es gibt 7 Auswahlmöglichkeiten für die Alternative php (welche /usr/bin/php bereitstellen).

  Auswahl      Pfad                  Priorität Status
------------------------------------------------------------
  0            /usr/bin/php.default   100       automatischer Modus
  1            /usr/bin/php.default   100       manueller Modus
  2            /usr/bin/php7.4        74        manueller Modus
  3            /usr/bin/php8.1        81        manueller Modus
* 4            /usr/bin/php8.2        82        manueller Modus
  5            /usr/bin/php8.3        83        manueller Modus
  6            /usr/bin/php8.4        84        manueller Modus
  7            /usr/bin/php8.5        85        manueller Modus

Hier die entsprechende Nummer eingeben – in diesem Fall die 6 für PHP 8.4:

sudo update-alternatives --config php
Es gibt 7 Auswahlmöglichkeiten für die Alternative php (welche /usr/bin/php bereitstellen).

  Auswahl      Pfad                  Priorität Status
------------------------------------------------------------
  0            /usr/bin/php.default   100       automatischer Modus
  1            /usr/bin/php.default   100       manueller Modus
  2            /usr/bin/php7.4        74        manueller Modus
  3            /usr/bin/php8.1        81        manueller Modus
  4            /usr/bin/php8.2        82        manueller Modus
  5            /usr/bin/php8.3        83        manueller Modus
* 6            /usr/bin/php8.4        84        manueller Modus
  7            /usr/bin/php8.5        85        manueller Modus

Die Abfrage der Version zeigt, ob die Umstellung auf PHP 8.4 angenommen wurde.

php -v

PHP 8.4 FPM starten und Apache neu laden

Anschließend wird der neue FPM-Dienst aktiviert und gestartet:

sudo a2disconf php8.2-fpm
sudo apt install php8.4-fpm
sudo a2enconf php8.4-fpm

Der Neustart des Webservers aktiviert nun die aktuelle PHP-Version:

sudo service apache2 restart

Nextcloud-Konfiguration

Sollten in Nextcloud anschließend wieder die bekannten Fehlermeldungen erscheinen, sind diese am besten Schritt für Schritt abzuarbeiten. Dazu werden zunächst die neue php.ini geöffnet:

sudo nano /etc/php/8.4/fpm/php.ini

und anschließend die Werte für memory_limit sowie session.gc_maxlifetime gemäß den Empfehlungen angepasst:

memory_limit = 512M
session.gc_maxlifetime = 3600

Am Ende der php.ini werden außerdem noch die Einstellungen für den Zwischenspeicher OPcache ergänzt:

opcache.enable=1
opcache.interned_strings_buffer=64
opcache.max_accelerated_files=10000
opcache.memory_consumption=256
opcache.save_comments=1
opcache.revalidate_freq=1

Zur Optimierung von PHP 8.4 FPM können speziell auf einem Raspberry Pi 5 mit 8 GB RAM in der Datei www.conf

sudo nano /etc/php/8.4/fpm/pool.d/www.conf

die folgenden Werte angepasst werden. Standardmäßig stehen dort in der Regel:

pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

Diese werden dann auf folgende Werte geändert:

pm = dynamic
pm.max_children = 200
pm.start_servers = 20
pm.min_spare_servers = 10
pm.max_spare_servers = 30

Anschließend wird der Dienst neu gestartet:

sudo service php8.4-fpm restart

Danach muss in der apcu.ini noch das Command Line Interface (CLI) des PHP-Caches aktiviert werden. Dazu die Datei öffnen:

sudo nano /etc/php/8.4/mods-available/apcu.ini

und am Ende folgende Zeile ergänzen:

apc.enable_cli=1

Ist dies geschehen, wird der Webserver ein letztes Mal neu gestartet:

sudo service apache2 restart

Nextcloud prüfen

Danach sollte die Nextcloud-Instanz im Browser aufgerufen werden. Unter Administrationseinstellungen / System lässt sich kontrollieren, ob die neue PHP-Version erkannt wurde.

Zur Sicherheit zusätzlich die Logdateien von Apache, PHP-FPM und Nextcloud prüfen.

Fazit

Die Umstellung von PHP 8.2 auf PHP 8.4-fpm für Nextcloud 32 ist unter Raspberry Pi OS schnell erledigt. Wichtig ist vor allem, die benötigten PHP-Module zu installieren und anschließend die alte FPM-Konfiguration sauber durch die neue zu ersetzen.

Der Beitrag PHP 8.4 FPM für Nextcloud 33 erschien zuerst auf intux.de.

Ein neuer adminForge Service kann ab sofort genutzt werden.

Euer adminForge Team

Das Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld. Unterstütze unsere Arbeit mit einer Spende und diskutiere in unserem Chat mit.

by adminForge.

Anfang Oktober 2025 hat das Raspberry Pi OS ein Upgrade auf Version 13 mit dem Codenamen Trixie erhalten. Dies setzt die Serverbetreiber wieder einmal mächtig unter Druck, obwohl Bookworm noch weitere Jahre unterstützt wird. Die Entwickler empfehlen eine Neuinstallation. Es ist immer von Vorteil, ein Betriebssystem wie im Falle von Trixie neu und somit sauber aufzusetzen. Da ich aber seit Jahren eine gut funktionierende Nextcloud-Instanz auf meinem Raspberry Pi pflege, die ich in meinem Alltag produktiv einsetze, wäre es zu schade, noch einmal ganz von vorn anfangen zu müssen. Aus diesem Grund war ich auf der Suche nach einem funktionierenden Tutorial für das anstehende OS-Upgrade. Schon beim Umstieg auf Bookworm war der Blog von Sascha Syring sehr hilfreich. Also hoffte ich auch dieses Mal, wieder hier fündig zu werden. Der Artikel „Raspberry Pi OS – Update von Bookworm (12) auf Trixie (13)“ von Sascha beschreibt einmal mehr die genaue Vorgehensweise.

Ich konnte somit alles 1:1 mit meinem System umsetzen. Hier nun alle Schritte mit den entsprechenden Erläuterungen.

Bevor es jedoch losgeht, noch ein wichtiger Hinweis:

Denkt bitte daran, vorher ein Backup zu erstellen! Das Upgrade birgt nicht zu unterschätzende Gefahren.

Upgrade auf Trixie

Zuerst sollte man dafür sorgen, das System inklusive Kernel und aller Abhängigkeiten auf den neuesten Stand zu bringen. Hierzu führt man folgenden Befehl aus:

sudo apt update && sudo apt full-upgrade

Vorbereitend wurde in meinem Fall die alte PHP-Fremd-Quelle deaktiviert.

Hierzu setzt man eine Raute (#) vor den Eintrag, öffnet dazu die php.list mit einem Editor

sudo nano /etc/apt/sources.list.d/php.list

und kommentiert die Zeile entsprechend aus:

#deb https://packages.sury.org/php/ bullseye main

Danach werden die hauseigenen Quellen des Raspberry Pi OS auf Trixie umgestellt:

sudo nano /etc/apt/sources.list

Hierzu wird in allen Quellen wie folgt bookworm durch trixie ersetzt:

deb http://deb.debian.org/debian trixie main contrib non-free non-free-firmware
deb http://security.debian.org/debian-security trixie-security main contrib non-free non-free-firmware
deb http://deb.debian.org/debian trixie-updates main contrib non-free non-free-firmware

Das Gleiche führt man analog hier durch:

sudo nano /etc/apt/sources.list.d/raspi.list

deb http://archive.raspberrypi.org/debian/ trixie main

Da beim ersten Versuch des Upgrades noch einiges schieflief, möchte ich an dieser Stelle darauf hinweisen, dass das Entfernen folgender Pakete für das Gelingen extrem wichtig ist!

sudo apt purge -y raspberrypi-ui-mods
sudo apt purge -y lxplug-batt
sudo apt purge -y lxplug-cpu

Ist dies erledigt, startet man via

sudo apt update && sudo apt full-upgrade

das eigentliche Upgrade. Hierzu ist noch zu erwähnen, dass bei den Abfragen zu alten Konfigurationen diese erhalten bleiben sollen. An diesen Stellen also bitte immer die Vorgabe (N) während der Installation wählen.

Die Pakete rpd-wayland-all und rpd-x-all werden noch nachinstalliert:

sudo apt install rpd-wayland-all rpd-x-all

Aufgeräumt wird mit:

sudo apt autoremove
sudo apt clean

und das System wird neu gestartet:

sudo reboot now

Überprüfung

Nach dem Neustart sollte der Befehl

sudo cat /etc/os-release

nun Folgendes ausgeben:

PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.4
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Feintuning

Da der NetworkManager nach dem Neustart noch nicht arbeitet, sollte er mit

sudo systemctl enable NetworkManager && sudo systemctl start NetworkManager

aktiviert und gestartet werden.

PHP-Quelle wieder einbinden

Am Anfang der Anleitung hatte ich die PHP-Quelle auskommentiert. Das machen wir nun wieder rückgängig. Erscheint nun nach einem Update der Hinweis, dass der zugehörige Schlüssel abgelaufen ist, löscht man diesen, lädt den aktuellen herunter und liest ihn neu ein.

sudo rm -f /usr/share/keyrings/deb.sury.org-php.gpg
sudo curl -sSLo /etc/apt/trusted.gpg.d/sury-php.gpg https://packages.sury.org/php/apt.gpg

Die Paketquellen werden nun abermals eingelesen und das System aktualisiert:

sudo apt update && sudo apt upgrade

Da die PHP-Quelle allerdings noch nicht für Trixie optimiert ist, ersetzt man auch hier bookworm bzw. bullseye durch trixie:

sudo nano /etc/apt/sources.list.d/php.list

#deb https://packages.sury.org/php/ bullseye main

Ein weiteres Mal werden die Paketquellen eingelesen und das System aktualisiert:

sudo apt update && sudo apt upgrade

Ist dies geschehen, ist das Upgrade von Raspberry Pi OS Version 12 auf 13 abgeschlossen.

Viel Erfolg bei der Umsetzung!

Der Beitrag Raspberry Pi OS Bookworm -> Trixie erschien zuerst auf intux.de.

Thunderbird stellt seine Entwicklung neu auf und zeigt mehr Offenheit. Die Macher veröffentlichen erstmals öffentliche Roadmaps, die auch für weniger technikaffine Nutzer verständlich bleiben. Damit soll klarer werden, wohin sich der Mailclient in den kommenden Jahren bewegt. Das Projekt erlebt derzeit eine Phase großer Veränderungen. Neben Windows, macOS und Linux wächst Thunderbird seit der Übernahme […]

Der Beitrag Thunderbird zeigt klare Zukunftspläne erschien zuerst auf fosstopia.

63% Prozent der befragten europäischen Unternehmen verwenden Open-Source-Software.

GNOME 48.10 wurde vom GNOME Projekt veröffentlicht und markiert den letzten Wartungsschritt dieser Serie. Die Aktualisierung bringt viele gezielte Fehlerbehebungen, die den Desktop spürbar stabiler machen. Mehrere Kernkomponenten erhalten Verbesserungen, die sich direkt im Alltag bemerkbar machen. GNOME Shell reagiert nun zuverlässiger nach dem Aufwachen des Systems. Probleme mit der Tastaturauswahl und der Navigation in […]

Der Beitrag GNOME 48.10 schließt die Serie mit wichtigen Korrekturen ab erschien zuerst auf fosstopia.

Mozilla hat Thunderbird 149 veröffentlicht und liefert ein Update mit spürbaren Verbesserungen. Nutzer können nun einzelne Kontakte exportieren und so Adressbücher leichter sichern. Markierte Nachrichten in EWS Konten bleiben zudem endlich auf allen Geräten erhalten. Neue Adressbücher entstehen nun direkt im Account Hub. Die Einrichtung wirkt dadurch klarer und zentraler. Viele Fehler im Verfassen-Fenster wurden […]

Der Beitrag Thunderbird 149 bringt viele wichtige Korrekturen erschien zuerst auf fosstopia.

Die neue Version 3.5 des OpenShot Video Editor bringt große Verbesserungen in der Performance mit schnellerer Timeline, verbesserter Audiobearbeitung und mehr Stabilität.

Open-Source-Entwickler sind durch KI-Meldungen massiv überlastet. Die Linux Foundation und Tech-Unternehmen kündigen nun Hilfe an.

Software-Beschaffung für öffentliche Verwaltungsbehörden sind durch die EVB-IT geregelt.

Das beliebte Open-Source-Bildbearbeitungstool GIMP veröffentlicht ein Jahr nach Beginn der Entwicklungsphase die Version 3.2.

Ab September 2026 müssen sich Entwickler bei Google registrieren, damit ihre Apps auf Android-Geräten installiert werden können.

GitHub Store ist ein kostenfreier Open-Source-App-Store, der plattformübergreifendes Herunterladen und Installieren direkt von GitHub anbietet.

sudo-rs hat sich zum Ziel gesetzt, einen Ersatz für das klassische sudo bereitzustellen. Dabei setzt das Projekt auf Rust, um eine "safety oriented and memory safe implementation" zu realisieren.

Hintergrund

Kurz zum Hintergrund: sudo unterscheidet sich von normalen Kommandos dadurch, dass das setuid-Flag der Binary gesetzt ist und das Programm beim Aufruf direkt mit Root-Rechten gestartet wird. Die Privilege Escalation ist wiederum die Voraussetzung dafür, dass ein Nutzer nach erfolgreicher Authentifizierung Root-Rechte annehmen kann. Sind jedoch im sudo-Programm selbst Bugs vorhanden, wird die Rechteerweiterung zum Sicherheitsrisiko. Wichtig an dieser Stelle: Privilege Escalation bezeichnet zunächst nur die Technik. Sie tritt häufig als Folge von Sicherheitslücken auf, hat aber auch legitime Einsatzszenarien.

Die gesamte Sicherheit hängt also von den Werkzeugen ab, die über setuid-Privilegien verfügen. Genau hier möchte sudo-rs ansetzen und eine Implementierung anbieten, die vom Speichersicherheitsmodell von Rust profitiert, um das Risiko bisher unentdeckter Sicherheitslücken in der Speicherverwaltung zu reduzieren.

Neue Darstellung von Passwörtern

Dass sudo-rs kein vollständiges Drop-in-Replacement wird, zeigt die Änderung, dass Passwörter nun standardmäßig in der Konsole maskiert angezeigt werden. Bisher hat sudo jegliche Ausgabe unterdrückt.

Administratoren, die dieses Verhalten abstellen wollen, können Defaults !pwfeedback in die sudoers-Datei einfügen. Das ist insbesondere dann relevant, wenn andere Programme davon abhängen, z. B. in Unit-Tests.

Die spannende Frage, die sich hierbei natürlich stellt, betrifft die Sicherheit. Natürlich ergibt sich ein neuer Seitenkanal, da ein Angreifer, der auf den Bildschirm schauen kann, die Länge des Passworts erfährt. Dabei sollte man allerdings im Hinterkopf behalten, dass bereits vor 25 Jahren demonstriert wurde, dass aus SSH-Sitzungen anhand der Paket-Timings während der Tastenanschläge Passwörter rekonstruiert werden können. Für einen Angreifer mit Fähigkeiten zur Massenüberwachung ergeben sich demnach keine grundlegend neuen Informationen.

Mit Ubuntu 26.04 LTS dabei

sudo-rs wurde bereits in Ubuntu 25.10 eingeführt. Ubuntu 26.04 wird damit der erste LTS-Release sein, der das neue Tooling nutzt.