Die Art, wie Menschen Software entdecken, hat sich grundlegend verändert. Wer ein Open-Source-Projekt veröffentlicht, rechnet oft damit, dass Entwicklerinnen und Entwickler es über klassische Suchmaschinen oder GitHub-Suchen finden. Doch in der KI-Suche nach Open-Source-Projekten gelten andere Regeln. KI-gestützte Systeme wie Perplexity, ChatGPT Search oder der KI-Modus von Google lesen, interpretieren und bewerten Inhalte auf eine andere Weise als herkömmliche Crawler. Projekte, die für Menschen gut dokumentiert sind, werden von diesen Systemen längst nicht immer gefunden oder empfohlen. Das betrifft besonders Linux-Projekte und Open-Source-Software, deren Dokumentation oft technisch präzise, aber für KI-Modelle schwer interpretierbar ist. Dieser Artikel zeigt, welche Faktoren darüber entscheiden, ob ein Open-Source-Projekt in der KI-Suche auftaucht, und welche konkreten Schritte die Sichtbarkeit nachhaltig verbessern.

Warum KI-Suchsysteme Open-Source-Projekte anders bewerten

Traditionelle Suchmaschinen folgen einem klaren Prinzip: Sie crawlen Seiten, analysieren Links und vergeben Rankings nach algorithmischen Kriterien. KI-basierte Suchsysteme funktionieren anders. Sie lesen Texte wie ein Mensch, ziehen Schlussfolgerungen und synthetisieren Antworten aus mehreren Quellen gleichzeitig.

Für Open-Source-Projekte bedeutet das einen strukturellen Nachteil. Eine README-Datei auf GitHub ist für Entwickler lesbar, für ein KI-Modell jedoch oft ein Rätsel aus Abkürzungen, Kommandozeilenbefehlen und implizitem Fachwissen. Das Modell kann den Kontext nicht vollständig herstellen und lässt das Projekt in einer Antwort schlicht weg.

Hinzu kommt ein weiterer Faktor: KI-Systeme bevorzugen Quellen, die mehrfach zitiert werden, in strukturierten Formaten vorliegen und auf bekannten Plattformen gehostet werden. Ein gut gepflegtes Projekt auf einer unbekannten Domain hat es deutlich schwerer als ein weniger aktives Projekt mit starker Community-Präsenz auf Reddit, Hacker News oder einschlägigen Technik-Blogs.

Die Herausforderung für Open-Source-Projekte im KI-Zeitalter

Dokumentation, die KI-Modelle nicht verstehen

Die meisten Open-Source-Projekte dokumentieren, was ihre Software tut und wie sie installiert wird. Was fehlt, ist der Kontext: Warum existiert dieses Projekt? Welches Problem löst es besser als Alternativen? Für welche Zielgruppe ist es gedacht?

KI-Modelle beantworten Suchanfragen kontextuell. Wer fragt „Welches Tool eignet sich zum Monitoring unter Linux für kleine Teams?“, bekommt eine Antwort, die auf Projekten basiert, die genau diese Frage irgendwo in ihrer Dokumentation beantworten. Projekte, die nur Funktionen auflisten, tauchen in solchen Antworten nicht auf.

Fehlende Präsenz auf zitierfähigen Plattformen

KI-Suchsysteme bevorzugen Inhalte, die auf Plattformen mit hoher Autorität gehostet werden oder von solchen Plattformen verlinkt sind. Ein Open-Source-Projekt, das ausschließlich auf GitHub lebt, fehlt in Diskussionen, Tutorials und Fachartikeln, die als Quellen dienen könnten.

Für die KI-Suche nach Open-Source-Software zählt nicht allein die Qualität des Codes. Entscheidend ist, ob glaubwürdige Drittquellen über das Projekt sprechen. Ein einzelner Artikel auf einem bekannten Linux-Blog, der das Projekt erwähnt und erklärt, kann mehr bewirken als hundert GitHub-Sterne.

Technische Barrieren für KI-Crawler

Viele Projektwebseiten werden statisch generiert oder bestehen aus einfachen HTML-Seiten ohne strukturierte Daten. KI-Crawler haben Schwierigkeiten, solche Seiten in einen semantischen Zusammenhang zu setzen. Fehlende Schema-Markups, unklare Seitenhierarchien und das Fehlen von FAQ-Sektionen oder strukturierten Erklärungstexten verschlechtern die Chance, in einer KI-gestützten Antwort zu erscheinen.

Strategien, um ein Open-Source-Projekt in der KI-Suche sichtbar zu machen

Dokumentation für semantische Verständlichkeit umschreiben

Der erste Schritt ist eine Überarbeitung der bestehenden Dokumentation mit Blick auf semantische Klarheit. Statt einer reinen Funktionsliste sollte die Startseite oder README folgende Fragen beantworten: Was ist das Projekt in einem Satz? Welches spezifische Problem löst es? Für wen ist es geeignet? Was unterscheidet es von ähnlichen Projekten?

Diese Informationen müssen in fließendem, verständlichem Prosatext vorliegen, nicht nur als Stichpunkte. KI-Modelle extrahieren Bedeutung aus Sätzen, nicht aus Tabellen oder Befehlszeilen. Ein klar formulierter Einleitungsabsatz, der das Projekt in seinem Verwendungskontext beschreibt, ist wertvoller als eine vollständige Featureliste.

Externe Sichtbarkeit durch Community und Fachmedien aufbauen

Wer möchte, dass ein Projekt in der KI-Suche nach Open-Source-Software empfohlen wird, muss dafür sorgen, dass vertrauenswürdige Quellen darüber berichten. Das bedeutet konkret: Gastbeiträge auf Technik-Blogs, Diskussionen auf Plattformen wie Hacker News, Beiträge in Foren der Linux-Community sowie Erwähnungen in Podcasts oder Newslettern.

Hier kommt auch die Frage der KI-Sichtbarkeit in der Suche ins Spiel, denn KI-Systeme werten nicht nur die eigene Projektseite aus, sondern aggregieren Informationen aus einem breiten Netz externer Quellen. Je mehr unabhängige Stimmen ein Projekt erwähnen und positiv beschreiben, desto wahrscheinlicher landet es in einer KI-generierten Empfehlung.

Strukturierte Daten und technische Optimierungen umsetzen

Für Projekte mit eigener Webpräsenz lohnt sich die Implementierung von strukturierten Daten nach Schema.org. Besonders relevant sind Typen wie SoftwareApplication, FAQPage und HowTo. Diese Markups helfen KI-Crawlern, den Inhalt korrekt zu kategorisieren.

Zusätzlich verbessern eine klare URL-Struktur, kurze Ladezeiten und eine gut lesbare Sitemap die Indexierungsqualität. FAQ-Sektionen auf der Projektwebseite sind besonders wirkungsvoll, da KI-Suchsysteme häufig gestellte Fragen direkt als Antwortquellen verwenden.

Best Practices für nachhaltige Sichtbarkeit in der KI-Suche

Open-Source-Projekten, die in der KI-Suche gefunden werden möchten, empfiehlt sich eine Kombination aus inhaltlichen und technischen Maßnahmen:

Inhaltlich sollte die Dokumentation regelmäßig aktualisiert und um Anwendungsbeispiele, Vergleiche mit Alternativen sowie Use-Case-Beschreibungen erweitert werden. Echte Nutzungsszenarien, etwa Wie setze ich dieses Tool in einer CI/CD-Pipeline unter Ubuntu ein?, beantworten genau die Fragen, die Nutzerinnen und Nutzer an KI-Systeme stellen.

Technisch gilt: Die Projektwebseite sollte eigenständig sein und nicht ausschließlich auf GitHub-gerenderte Markdown-Dateien setzen. Eine dedizierte Seite mit klarer Struktur, Metadaten und strukturierten Inhalten wird von KI-Systemen konsistenter indexiert als eine reine Repository-Seite.

Aus Sicht der Community-Strategie zahlt es sich aus, aktiv in Diskussionen präsent zu sein, auf Fragen in Foren zu antworten und das Projekt in relevanten Kontexten zu erwähnen. Jede glaubwürdige Erwähnung auf einer externen Plattform erhöht die Wahrscheinlichkeit, dass ein KI-Modell das Projekt als relevante Quelle einstuft.

Häufig gestellte Fragen

Warum erscheint ein populäres Open-Source-Projekt trotzdem nicht in KI-Suchantworten?

Popularität gemessen in GitHub-Sternen oder Downloads korreliert nicht direkt mit der Sichtbarkeit in KI-Suchsystemen. Diese Systeme bevorzugen Projekte, über die in verständlicher Sprache auf zitierfähigen Plattformen berichtet wird. Ein Projekt mit 500 Sternen, über das ein bekannter Linux-Blog geschrieben hat, wird oft häufiger empfohlen als ein Projekt mit 5.000 Sternen ohne externe Berichterstattung.

Welche Plattformen sind für die KI-Suchoptimierung von Open-Source-Projekten besonders wichtig?

Besonders wirkungsvoll sind Plattformen mit hoher inhaltlicher Autorität: technische Blogs, Fachmagazine für Entwickler, Diskussionsplattformen wie Hacker News sowie spezialisierte Foren der Linux- und Open-Source-Community. Darüber hinaus werden Inhalte aus StackOverflow, Reddit (in relevanten Subreddits) und Dokumentationsseiten mit klarer Struktur von KI-Systemen häufig als Quellen genutzt.

Wie oft sollte die Dokumentation eines Open-Source-Projekts aktualisiert werden, um in der KI-Suche relevant zu bleiben?

Eine Faustregel ist, die Hauptdokumentation bei jedem größeren Release zu überarbeiten und dabei sicherzustellen, dass Anwendungsbeispiele und Problemlösungsszenarien aktuell bleiben. KI-Systeme gewichten frische Inhalte positiv, besonders wenn sich die Funktionen des Projekts weiterentwickelt haben. Mindestens einmal im Quartal sollte geprüft werden, ob die zentralen Seiten noch den aktuellen Stand des Projekts widerspiegeln.

Der Beitrag KI-Suche und Linux: Open-Source-Projekte sichtbar machen erschien zuerst auf intux.de.

Doch der Tech-Spleen lässt einen auch im Urlaub nicht ganz los. Mir ging da nämlich eine Sache durch den Kopf: Letztes Jahr hat Prof. Klaus Knopper auf den Chemnitzer Linux-Tagen einen extrem spannenden Vortrag zum Thema lokale KI gehalten. Konkret ging es um Ollama auf dem Raspberry Pi. Warum also nicht die freie Zeit nutzen, um das Ganze mal aus der Ferne auf dem heimischen RasPi zu installieren und selbst auszuprobieren?

Was ist Ollama?

Für alle, die den Begriff noch nicht gehört haben, hilft ein kurzer Blick in die Wikipedia:

Ollama ist eine Open-Source-Software zur lokalen Ausführung von Large Language Models (LLMs) auf Desktop-Computern. Die Plattform ermöglicht die lokale Nutzung frei verfügbarer KI-Modelle und unterstützt die Integration mit weiteren lokalen Werkzeugen, die über eine Kommandozeilenschnittstelle oder eine Programmierschnittstelle (API) angebunden werden können. Ollama ist für macOS, Linux und Windows verfügbar.

Installation

Gesagt, getan. Die Installation auf dem Raspberry Pi – in meinem Fall ein Raspberry Pi 5 mit 8 GB RAM – erfolgt denkbar einfach über das Terminal mit folgendem Befehl:

curl -fsSL https://ollama.com/install.sh | sh

Am Ende des Installationsvorgangs spuckt das System noch den dezenten Hinweis aus, dass keine NPUs oder Grafikkarten von Nvidia gefunden wurden, die die Ausführung des Large Language Models beschleunigen könnten. Das war beim RasPi natürlich zu erwarten, hält uns aber nicht auf.

Damit wir der KI überhaupt Fragen stellen können, muss im Anschluss ein passendes und vor allem schlankes Modell installiert werden. Für diesen ersten Test habe ich mich für Llama 3.2 (ca. 2 GB) entschieden:

ollama run llama3.2:3b

Der Praxistest: Was taugt die lokale KI?

Nachdem das Modell geladen war, wollte ich es natürlich wissen. Ich habe der lokalen KI eine klassische Frage gestellt:

Welche Linux-Distribution würdest du einem Anfänger empfehlen?

Eine gute Frage!

Als Anfänger ist es wichtig, eine Linux-Distribution zu wählen, die leicht zu installieren und zu bedienen ist. Hier sind einige beliebte Optionen:

1. Ubuntu: Ubuntu ist eine der bekanntesten und am weitesten verbreiteten Linux-Distributionen. Sie bietet eine intuitive Benutzeroberfläche und eine riesige Gemeinschaft von Benutzern, die ihr helfen können, wenn
   etwas nicht funktioniert.
2. Linux Mint: Linux Mint basiert auf Ubuntu und ist für ihre einfache und benutzerfreundliche Oberfläche bekannt. Sie ist auch sehr sicher und bietet viele zusätzliche Funktionen wie eine verbesserte
   Sicherheitsfunktion und eine integrierte Diskografie.
3. Debian: Debian ist eine weitere beliebte Linux-Distribution, die für ihre Stabilität und Sicherheit bekannt ist. Sie bietet eine riesige Auswahl an Software und ist ein beliebter Kandidat für Entwickler und
   Systemadministratoren.
4. Fedora: Fedora ist eine Linux-Distribution, die von der Open Source Initiative verwaltet wird. Sie bietet eine aktuelle und sichere Version von Linux und ist ein beliebter Kandidat für Entwickler und
   Systemadministratoren.

Meine Empfehlung wäre Ubuntu. Sie ist eine großartige Option für Anfänger, da sie leicht zu installieren und zu bedienen ist. Außerdem bietet sie eine riesige Gemeinschaft von Benutzern, die ihr helfen können, wenn
etwas nicht funktioniert.

Ich hoffe, das hilft! Wenn du noch weitere Fragen hast, stehe ich gerne zur Verfügung.

Das Ergebnis kann sich absolut sehen lassen. Die Antwort hätte ich so oder so ähnlich wahrscheinlich auch gegeben. Ich bin wirklich nachhaltig beeindruckt, was der kleine Einplatinen-Computer hier ganz ohne Cloud-Anbindung zu leisten vermag.

Fazit

Eine lokale und ethische KI auf dem eigenen Raspberry Pi ist auf jeden Fall einen Blick wert. Wer seine Daten nicht ungeschützt den großen Hyperscalern in die Cloud blasen möchte, findet hier eine fantastische Alternative. Im Sinne der digitalen Souveränität ist diese Lösung für kleinere, alltägliche Aufgaben auf jeden Fall hervorragend geeignet.

Der Beitrag Urlaub mit dem Lama erschien zuerst auf intux.de.

Wer kennt es nicht: Unter Linux ist nahezu alles machbar, was man an einem Computer tun kann – von der Textverarbeitung über Grafikdesign bis hin zur Erstellung eigener Webseiten oder Videos mit faszinierenden Tonspuren. Dennoch weiß man oft nicht, welches Programm oder Tool für die jeweilige Aufgabe am sinnvollsten einzusetzen wäre. Langes Stöbern und Recherchieren ist oft notwendig, bis das richtige Programm gefunden ist. Abgesehen von all den grafischen Anwendungen für Linux findet man etliche Programme und Kommandos, die sich im Terminal ausführen lassen. Eine komplexe Übersicht hierzu gibt das Buch „Linux Kommandoreferenz: Shell-Befehle von A bis Z“ aus dem Rheinwerk Verlag.

Der Autor und Linux-Experte Michael Kofler gibt dem Leser nicht nur eine große Auswahl von Kommandos, sondern auch die wichtigsten Optionen mit ausreichenden Erklärungen an die Hand und weist zudem auf die umfangreichen Manual-Seiten (man pages) des Linux-Systems hin. Über den Befehl tldr lassen sich auch direkte Anwendungsbeispiele zu den einzelnen Kommandos ausgeben.

Nicht nur Kommandos mit den entsprechenden Optionen werden thematisiert, sondern auch die wichtigsten Konfigurationsdateien besprochen – genauso wie Tastenkürzel, die den Anwender schneller zum Ziel führen. Das Buch ist dabei wie ein echtes Werkzeug aufgebaut: Dank einer klaren Gliederung nach Themenbereichen wie Systemadministration, Netzwerk oder Programmierung findet man sofort den passenden Befehl. Ein besonderes Highlight des Verlagsdesigns ist das hilfreiche Griffregister am Buchrand, das wie ein Daumenkino funktioniert und das Nachschlagen im Terminal-Alltag enorm beschleunigt.

Leseprobe

• Leseprobe

Fazit

Dieses Buch besticht durch inhaltliche Tiefe und Aktualität. Das Linux-Ökosystem ist ständig im Wandel, was die mittlerweile 6. Auflage dieses Klassikers deutlich zeigt. Kofler geht auf viele Befehle bzw. Kommandos ein und erklärt sie bildhaft an Beispielen. Rheinwerk liefert hier gewohnt hohe Qualität mit einem robusten Hardcover, das für den täglichen Einsatz auf dem Schreibtisch gemacht ist. Ein Buch, um noch tiefer in die Arbeit mit dem Terminal einzusteigen – egal ob als Einsteiger, Student oder erfahrener Administrator.

Der Beitrag Linux Kommandoreferenz: Shell-Befehle von A bis Z erschien zuerst auf intux.de.

​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.

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.

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.

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.

Hierfür wird auf Linux-Systemen das Tool smartmontools benötigt. Die ausgelesenen Daten liefern wertvolle Hinweise auf mögliche Probleme mit dem Medium – bevor es zu einem Ausfall kommt.

Installation

Unter Debian-basierten Systemen ist smartmontools in den Paketquellen enthalten und schnell installiert:

sudo apt install smartmontools

S.M.A.R.T.-Werte abfragen

Um die aktuellen Werte eines Laufwerks auszulesen, genügt folgender Befehl:

sudo smartctl -a /dev/sdX

/dev/sdX steht dabei stellvertretend für das jeweilige Laufwerk, etwa /dev/sda oder /dev/nvme0n1 für NVMe-SSDs. Die Option -a sorgt dafür, dass alle verfügbaren Informationen ausgegeben werden.

Wichtig: sdX ist ein Platzhalter und muss durch die tatsächliche Bezeichnung des zu prüfenden Laufwerks ersetzt werden.

Was die Ausgabe verrät

Die Ausgabe von smartctl ist recht umfangreich und auf den ersten Blick etwas unübersichtlich. Neben allgemeinen Informationen wie Modell, Firmware-Version und Seriennummer finden sich dort auch die sogenannten S.M.A.R.T.-Attribute. Diese zeigen unter anderem wichtige Messwerte wie:

• den allgemeinen Gesundheitszustand (SMART overall-health self-assessment test result)
• die Temperatur des Laufwerks (Temperature)
• die Verfügbare Reserve (Available Spare)
• den Reserve-Schwellenwert (Available Spare Threshold)
• die verbrauchte Lebensdauer (Percentage Used)
• die gelesenen Dateneinheiten (Data Units Read)
• die geschriebenen Dateneinheiten (Data Units Written)

Ein Beispiel:

sudo smartctl -a /dev/nvme0n1

...
SMART overall-health self-assessment test result: PASSED
Temperature: 45 Celsius
Available Spare: 100%
Available Spare Threshold: 50%
Percentage Used: 4%
Data Units Read: 37.885.790 [19,3 TB]
Data Units Written: 28.019.142 [14,3 TB]
...

Für eine kurze Abfrage des Gesundheitszustands reicht hingegen:

sudo smartctl -H /dev/sdX

Ein Beispiel:

sudo smartctl -H /dev/nvme0

...
SMART overall-health self-assessment test result: PASSED
...

Fazit

Mit smartctl hat man unter Linux ein mächtiges Werkzeug zur Hand, um die Gesundheit von Laufwerken zu prüfen. Gerade bei älteren Festplatten lohnt sich ein regelmäßiger Blick auf die S.M.A.R.T.-Werte. Im Ernstfall können sie vor Datenverlust warnen – und geben den entscheidenden Anstoß, ein Backup nicht weiter aufzuschieben.

Der Beitrag Gesundheit der Festplatte überprüfen erschien zuerst auf intux.de.

Was sind Bad Sektoren?

Bad Sektoren sind physisch oder logisch beschädigte Bereiche auf einem Datenträger. Physische Defekte entstehen durch Abnutzung, mechanische Schäden oder Produktionsfehler. Logische Bad Sektoren hingegen resultieren meist aus Softwareproblemen oder Stromausfällen und lassen sich mitunter korrigieren.

Analysewerkzeuge unter Linux

Linux bietet verschiedene Werkzeuge zur Analyse und Erkennung defekter Sektoren. Eines der bekanntesten Tools ist badblocks.

Ein einfacher Check lässt sich wie folgt durchführen:

sudo badblocks -vsn /dev/sdX

Ersetzt man dabei /dev/sdX durch das entsprechende Gerät, erhält man einen Überblick über den Zustand der Sektoren. Hierbei sucht badblocks gezielt nach defekten Blöcken der Festplatte.

Dabei sollte beachtet werden, dass dieser Vorgang – je nach Größe des Datenträgers – einige Zeit in Anspruch nehmen kann.

Fazit

Die regelmäßige Analyse auf Bad Sektoren ist ein wichtiger Bestandteil der Systempflege. Frühzeitig erkannte Fehler ermöglichen rechtzeitige Backups und gegebenenfalls den Austausch der betroffenen Hardware. Open-Source-Werkzeuge wie badblocks bieten unter Linux zuverlässige Möglichkeiten zur Diagnose – ganz ohne proprietäre Software.

Der Beitrag Überprüfung auf fehlerhafte Sektoren erschien zuerst auf intux.de.

Neulich bin ich auf ein solches Verhalten gestoßen, als ich Bilder, die mir von einem Fotografen übergeben wurden, in WordPress zur Weiterverarbeitung hochladen wollte. Zuvor hatte ich die Größen der Dateien in einer Stapelverarbeitung über das Terminal angepasst. Danach habe ich die Dateinamen nach bestimmten Vorgaben umbenannt.

Nachdem das erledigt war, habe ich das Bildmaterial in die Mediathek der Webseite hochgeladen. Dabei fiel mir auf, dass die Bezeichnungen der Bilder nicht den neuen Dateinamen entsprachen. Stattdessen trugen sie die Bezeichnung der Veranstaltung, bei der sie aufgenommen wurden. Ein Löschen und erneutes Hochladen der Fotos konnte das Problem nicht beheben.

Schnell lag der Verdacht nahe, dass in den Bilddateien selbst noch Informationen gespeichert waren, die von WordPress beim Hochladen automatisch übernommen wurden. Im konkreten Fall handelte es sich um Metadaten in der IPTC-Kopfzeile. Bei knapp 100 Bildern wäre es sehr aufwendig gewesen, diese Angaben manuell zu entfernen. Eine Lösung über eine Stapelverarbeitung war daher naheliegend, am besten direkt über das Terminal unter Ubuntu.

Glücklicherweise gibt es eine einfache Möglichkeit, solche eingebetteten Informationen automatisch aus den Dateien zu entfernen.

Zuvor muss allerdings das Paket libimage-exiftool-perl installiert werden.

sudo apt install libimage-exiftool-perl

Danach wird folgender Befehl im Verzeichnis, in dem die zu bearbeitenden Bilder liegen, ausgeführt:

exiftool -all= *.jpg

Dieser sorgt dafür, dass die Dateiendungen der Originalbilder in .jpg_original geändert und die Metadaten aus den eigentlichen Bilddateien entfernt werden.

Beim anschließenden Upload in WordPress wurden die Bildbezeichnungen wie gewünscht angezeigt – also die neuen Dateinamen mit passender Nummerierung.

Der Beitrag Metadaten aus Fotos entfernen erschien zuerst auf intux.de.