Eine interne NTFS-Festplatte lässt sich unter Linux Mint problemlos lesen, aber nicht beschreiben. Dateien können geöffnet werden, beim Anlegen oder Ändern von Dateien scheitert der Zugriff jedoch.

In meinem Fall war die Partition noch in einem unsauberen NTFS-Zustand. Nach einer Reparatur mit ntfsfix und einem expliziten Mount mit ntfs-3g ließ sie sich wieder normal beschreiben.

Das Problem

Die NTFS-Partition war vorhanden und lesbar, Schreibzugriffe funktionierten aber nicht.

Zunächst sollte man herausfinden, unter welchem Gerätenamen Linux die betreffende Partition kennt:

lsblk -f

Eine typische Ausgabe sieht beispielsweise so aus:

NAME   FSTYPE LABEL
sda
└─sda1 ntfs   Fotos
sdb
└─sdb1 ntfs   Dokumente

Wichtig ist der Unterschied zwischen Gerät und Mountpoint:

/dev/sda1

ist die eigentliche Partition.

Ein Pfad wie

/media/benutzer/Fotos

oder

/mnt/fotos

ist dagegen nur das Verzeichnis, in das diese Partition eingehängt wurde.

Programme wie ntfsfix benötigen das Gerät, also beispielsweise:

sudo ntfsfix /dev/sda1

und nicht den Mountpoint.

Ursache: NTFS war als „unclean“ markiert

Nach dem Aushängen der Partition wurde sie mit ntfsfix überprüft:

sudo umount /dev/sda1
sudo ntfsfix -d /dev/sda1

Dabei meldete ntfsfix unter anderem:

The disk contains an unclean file system
Metadata kept in Windows cache, refused to mount.

Anschließend wurden unter anderem die Master File Table und deren Spiegel geprüft sowie das NTFS-Journal geleert.

Der Vorgang endete mit:

NTFS partition /dev/sda1 was processed successfully.

Damit war zumindest belegt, dass die Partition zuvor tatsächlich einen unsauberen NTFS-Zustand hatte und ntfsfix diesen bearbeitet hatte.

ntfsfix ist dabei keine vollständige NTFS-Reparatur wie ein Windows-chkdsk. Für grundlegende Inkonsistenzen und das Zurücksetzen des NTFS-Journals kann es aber ausreichen.

Einen festen Mountpoint anlegen

Beim anschließenden manuellen Mounten trat zunächst ein weiterer Fehler auf:

failed to access mountpoint ...: Datei oder Verzeichnis nicht gefunden

Der Grund war simpel: Das Zielverzeichnis existierte nach dem Aushängen nicht mehr.

Deshalb zuerst einen festen Mountpoint anlegen:

sudo mkdir -p /mnt/ntfs-daten

Danach kann die Partition mit ntfs-3g explizit als beschreibbar eingehängt werden:

sudo mount -t ntfs-3g \
  -o rw,uid=1000,gid=1000,umask=022 \
  /dev/sda1 /mnt/ntfs-daten

Die Werte 1000 waren in diesem Fall Benutzer- und Gruppen-ID des normalen Linux-Benutzers. Die eigenen Werte lassen sich prüfen mit:

id -u
id -g

Prüfen, ob die Partition wirklich schreibbar ist

Der aktuelle Mount-Status lässt sich zum Beispiel so kontrollieren:

mount | grep sda1

Im erfolgreichen Fall erschien:

/dev/sda1 on /mnt/ntfs-daten type fuseblk (rw,...)

Entscheidend ist hier:

rw

Das Dateisystem ist also read/write eingehängt.

Ein einfacher Schreibtest ist:

touch /mnt/ntfs-daten/testdatei.txt

Wenn dabei keine Fehlermeldung erscheint, funktioniert der Schreibzugriff.

Die Testdatei kann anschließend wieder entfernt werden:

rm /mnt/ntfs-daten/testdatei.txt

Damit war der Schreibzugriff in diesem Fall praktisch bestätigt.

NTFS dauerhaft über /etc/fstab einbinden

Damit die Platte nicht nach jedem Neustart manuell gemountet werden muss, kann sie in /etc/fstab eingetragen werden.

Zunächst einen dauerhaften Mountpoint anlegen:

sudo mkdir -p /mnt/ntfs-daten

Vor Änderungen an fstab empfiehlt sich eine Sicherung:

sudo cp /etc/fstab /etc/fstab.bak

Danach:

sudo nano /etc/fstab

Für die Partition kann beispielsweise folgende Zeile verwendet werden:

UUID=DEINE-UUID  /mnt/ntfs-daten  ntfs-3g  rw,uid=1000,gid=1000,umask=022,nofail,x-gvfs-show  0  0

Die UUID findet man mit:

lsblk -f

oder:

sudo blkid

Die wichtigsten Optionen:

rw

bindet die Partition beschreibbar ein.

uid=1000,gid=1000

ordnet die Dateien dem angegebenen Benutzer und seiner Gruppe zu.

umask=022

setzt passende Standardrechte.

nofail

verhindert, dass ein Problem mit diesem Datenträger den normalen Systemstart blockiert.

x-gvfs-show

kann dafür sorgen, dass die Partition auch im grafischen Dateimanager angezeigt wird.

Änderungen an fstab testen

Nach dem Speichern kann die Konfiguration getestet werden:

sudo mount -a

Wurde /etc/fstab während des laufenden Systems geändert, kann systemd darauf hinweisen, dass noch die alte Konfiguration verwendet wird:

Ihre Fstab-Datei wurde geändert, aber Systemd nutzt
noch die alte Version

Dann kann die systemd-Konfiguration neu geladen werden:

sudo systemctl daemon-reload

Fallstrick: „NTFS volume is already exclusively opened“

Beim Einrichten mehrerer NTFS-Platten trat außerdem folgende Meldung auf:

Mount is denied because the NTFS volume is already exclusively opened.
The volume may be already mounted, or another software may use it

In diesem Fall waren die betreffenden Partitionen bereits an anderen Mountpoints eingehängt.

Das lässt sich überprüfen mit:

mount | grep ntfs

oder gezielter:

findmnt

Ein NTFS-Volume sollte nicht gleichzeitig noch an einem alten Automount-Pfad hängen und zusätzlich über einen neuen fstab-Mountpoint eingebunden werden.

Vor einem erneuten Mount-Versuch muss deshalb gegebenenfalls zunächst der bereits vorhandene Mount ausgehängt werden.

Beispiel:

sudo umount /alter/mountpoint

Danach:

sudo mount -a

Neustart nach größeren fstab-Änderungen

Nach mehreren Änderungen an Mountpoints und /etc/fstab ist ein Neustart eine einfache Möglichkeit, mit einem definierten Zustand zu beginnen.

Beim Booten wird die fstab erneut verarbeitet.

sudo reboot

Hinweis: Im hier dokumentierten Ablauf wurde der Neustart als nächster Schritt vorgesehen, sein Ergebnis wurde aber nicht mehr überprüft. Der erfolgreiche Schreibzugriff auf die erste NTFS-Partition war zu diesem Zeitpunkt bereits unabhängig davon bestätigt.

Ergebnis

Der entscheidende Ablauf war:

lsblk -f

richtige NTFS-Partition ermitteln,

sudo umount /dev/sdXN
sudo ntfsfix -d /dev/sdXN

unsauberen NTFS-Zustand bearbeiten,

sudo mkdir -p /mnt/ntfs-daten

einen festen Mountpoint anlegen und anschließend:

sudo mount -t ntfs-3g \
  -o rw,uid=1000,gid=1000,umask=022 \
  /dev/sdXN /mnt/ntfs-daten

beschreibbar mounten.

Der Test:

touch /mnt/ntfs-daten/testdatei.txt

lief anschließend ohne Fehler durch.

Damit war die zuvor nur lesbare NTFS-Festplatte unter Linux Mint wieder beschreibbar.

# Linux Mint: Zweiter Monitor verschwunden – NVIDIA-Treiber durch Secure Boot blockiert

Nach einem Start von Linux Mint funktionierte plötzlich nur noch einer von zwei Bildschirmen. Die Grafikkarte wurde grundsätzlich erkannt, der NVIDIA-Treiber aber offenbar nicht korrekt geladen.

Da parallel Windows 11 installiert war und UEFI Secure Boot aktiviert war, lag der Verdacht nahe, dass Secure Boot eine Rolle spielen könnte. Statt Secure Boot sofort im UEFI abzuschalten, ließ sich die Ursache zunächst unter Linux genauer prüfen.

## Das Problem

Das auffälligste Symptom:

- nur ein Bildschirm wurde erkannt,
- die NVIDIA-Grafikkarte war vorhanden,
- die eigentliche Grafikbeschleunigung funktionierte aber nicht.

Ein erster Check mit:

```bash
xrandr
inxi -Gxx
lspci | grep -Ei 'vga|3d|display'

zeigte im konkreten Fall eine NVIDIA GeForce GTX 1650.

Entscheidend waren aber mehrere andere Hinweise aus inxi:

driver: N/A
gpu: N/A

Außerdem wurde als OpenGL-Renderer nur Software-Rendering verwendet:

renderer: llvmpipe

xrandr erkannte ebenfalls nur einen einzigen Ausgang.

Damit war bereits klar: Die Grafikkarte selbst wurde vom System gesehen, aber der NVIDIA-Treiber arbeitete nicht korrekt.

Ist Secure Boot wirklich die Ursache?

Zunächst ließ sich prüfen, ob Secure Boot überhaupt aktiv war:

mokutil --sb-state

Die Ausgabe:

SecureBoot enabled

belegt zunächst nur, dass Secure Boot eingeschaltet ist. Sie beweist noch nicht, dass Secure Boot auch den NVIDIA-Treiber blockiert.

Deshalb folgten weitere Prüfungen:

ubuntu-drivers devices

dpkg -l | grep -Ei 'nvidia|linux-modules-nvidia'

lsmod | grep -Ei 'nvidia|nouveau'

modinfo nvidia 2>/dev/null | grep -Ei 'filename|version|signer|sig_id'

journalctl -k -b | grep -Ei 'nvidia|secure boot|mok|module verification|lockdown|key'

Der entscheidende Befund

Die NVIDIA-Pakete waren installiert. Im konkreten Fall war unter anderem der offene NVIDIA-Kerneltreiber der 580er-Reihe vorhanden.

modinfo zeigte außerdem, dass das NVIDIA-Modul signiert war:

sig_id: PKCS#7
signer: localhost.localdomain Secure Boot Module Signature key

Im Kernel-Log erschienen gleichzeitig Meldungen wie:

secureboot: Secure boot enabled

und:

Kernel is locked down from EFI Secure Boot mode

Vor allem aber:

Loading of module with unavailable key is rejected

Damit war die Ursache nicht mehr nur eine Vermutung.

Der NVIDIA-Kerneltreiber war vorhanden und signiert, aber der dafür verwendete Schlüssel wurde von Secure Boot nicht als vertrauenswürdig akzeptiert. Das Modul wurde deshalb nicht geladen.

Lösung: MOK-Schlüssel eintragen statt Secure Boot abschalten

Secure Boot musste in diesem Fall nicht deaktiviert werden.

Stattdessen wurde der bereits vorbereitete Machine Owner Key, kurz MOK, zur Registrierung vorgemerkt:

sudo update-secureboot-policy --enroll-key

Darauf erschien ein textbasierter Dialog mit dem Hinweis, dass für die Verwendung von Drittanbieter-Treibern unter Secure Boot ein Machine Owner Key registriert werden müsse.

In diesem Dialog wurde ein Passwort vergeben.

Falls sich ein solcher Dialog nicht mit der Maus bedienen lässt, funktionieren typischerweise:

• Tab, um zwischen Schaltflächen zu wechseln,
• Pfeiltasten zur Navigation,
• Enter oder gegebenenfalls die Leertaste zur Bestätigung.

Danach wurde das System neu gestartet.

MOK beim Neustart bestätigen

Beim nächsten Start erschien der MOK-Manager.

Dort wurde der vorbereitete Schlüssel über den Menüpunkt

Enroll MOK

registriert und mit dem zuvor vergebenen Passwort bestätigt.

Secure Boot selbst blieb dabei aktiviert.

Anschließend startete Linux Mint wieder normal.

Ergebnis prüfen

Direkt nach dem Neustart funktionierten beide Monitore wieder.

Zusätzlich ließ sich der Zustand mit folgenden Befehlen kontrollieren:

mokutil --sb-state
lsmod | grep nvidia
nvidia-smi

Secure Boot war weiterhin aktiv:

SecureBoot enabled

Gleichzeitig waren nun die NVIDIA-Module geladen, unter anderem:

nvidia
nvidia_modeset
nvidia_drm
nvidia_uvm

Auch nvidia-smi erkannte die GeForce GTX 1650 wieder korrekt und zeigte den NVIDIA-Treiber als aktiv an.

Damit war der Fehler behoben.

Was hier tatsächlich passiert war

Der Ablauf ließ sich in diesem Fall eindeutig nachvollziehen:

1. Die NVIDIA-Grafikkarte wurde vom System erkannt.
2. Der NVIDIA-Kerneltreiber war installiert.
3. Das Kernelmodul war signiert.
4. Secure Boot war aktiviert.
5. Der verwendete Signaturschlüssel war nicht als vertrauenswürdig registriert.
6. Der Kernel verweigerte deshalb das Laden des NVIDIA-Moduls.
7. Linux fiel auf Software-Rendering zurück.
8. Dadurch stand auch die normale NVIDIA-Ausgabe für die angeschlossenen Monitore nicht zur Verfügung.
9. Nach Registrierung des MOK-Schlüssels konnte das Modul geladen werden.
10. Beide Bildschirme funktionierten wieder.

Diagnose in Kurzform

Wenn Linux Mint mit NVIDIA-Grafik plötzlich nur noch einen Monitor erkennt, kann folgende Reihenfolge sinnvoll sein:

mokutil --sb-state

xrandr
inxi -Gxx
lspci | grep -Ei 'vga|3d|display'

ubuntu-drivers devices
dpkg -l | grep -Ei 'nvidia|linux-modules-nvidia'
lsmod | grep -Ei 'nvidia|nouveau'

modinfo nvidia 2>/dev/null | grep -Ei 'filename|version|signer|sig_id'

journalctl -k -b | grep -Ei 'nvidia|secure boot|mok|module verification|lockdown|key'

Besonders aussagekräftig ist eine Kombination aus:

driver: N/A

oder Software-Rendering über:

llvmpipe

und Kernel-Meldungen wie:

Loading of module with unavailable key is rejected

Erst damit ist tatsächlich belegt, dass nicht nur ein allgemeines NVIDIA-Problem vorliegt, sondern die Vertrauenskette von Secure Boot das Laden des Moduls verhindert.

Fazit

In diesem Fall war das Abschalten von Secure Boot nicht nötig.

Die bessere Lösung bestand darin, den bereits signierten NVIDIA-Kerneltreiber über einen registrierten Machine Owner Key für Secure Boot vertrauenswürdig zu machen.

Der Vorteil: Der NVIDIA-Treiber funktioniert wieder, beide Monitore stehen zur Verfügung und Secure Boot kann aktiviert bleiben.

Für „Patches & Notes“ eignet sich das aus meiner Sicht gut als klassischer **Fehlerbild → Diagnose → belegte Ursache → Reparatur → Verifikation**-Artikel. Ich habe dabei bewusst die konkreten lokalen Hostnamen und den ausgegebenen lokalen Systempfad des MOK-Schlüssels weggelassen.

Beim Kopieren einer alten Festplatte mit rsync endete ein größerer Sicherungslauf mit:

rsync error: some files/attrs were not transferred
(code 23)

Gleichzeitig waren aber bereits hunderte Gigabyte erfolgreich am Ziel angekommen.

Die wichtige Frage war deshalb nicht:

Ist rsync fehlgeschlagen?

Sondern:

Welche Dateien fehlen tatsächlich?

Ausgangslage

Eine ältere NTFS-Festplatte sollte auf einen neuen Datenträger kopiert werden.

Verwendet wurde sinngemäß:

rsync -rlt --partial --info=progress2 \
"/media/user/ALTE_PLATTE/Backup" \
"/mnt/NEUE_PLATTE/"

Der Kopiervorgang lief lange normal.

Dann tauchten Meldungen wie diese auf:

read errors mapping "...": Input/output error (5)

und schließlich:

rsync error: some files/attrs were not transferred
(code 23)

---

Exit-Code 23 bedeutet nicht: nichts wurde kopiert

Bei einem großen Verzeichnisbaum kann rsync tausende Dateien erfolgreich übertragen und trotzdem am Ende mit Code 23 zurückkehren.

Im konkreten Fall wurden mehrere hundert Gigabyte übertragen.

Nur einzelne Dateien konnten wegen Lesefehlern der Quellfestplatte nicht erfolgreich kopiert werden.

Deshalb wäre es falsch gewesen, den kompletten Kopiervorgang als unbrauchbar anzusehen.

---

Entscheidend: endgültige Fehlermeldungen

Während des Laufs gab es vereinzelt Lesefehler bei Dateien, die später trotzdem übertragen werden konnten.

Besonders relevant waren dagegen Meldungen wie:

failed verification -- update discarded

Hier hatte rsync die Zieldatei nicht als erfolgreich übertragen akzeptiert.

Diese Dateien mussten später separat behandelt werden.

---

Warum rsync dafür praktisch ist

Ein großer Vorteil von rsync ist, dass ein Kopiervorgang erneut gestartet werden kann.

Bereits vorhandene Dateien müssen dabei nicht zwangsläufig komplett noch einmal übertragen werden.

Das ist gerade bei einer angeschlagenen Festplatte hilfreich:

Man möchte möglichst vermeiden, bereits erfolgreich gelesene Daten immer wieder unnötig von der problematischen Platte anzufordern.

---

—partial bei großen Dateien

Verwendet wurde außerdem:

--partial

Dadurch können teilweise übertragene Dateien erhalten bleiben.

Das kann insbesondere bei großen Dateien sinnvoll sein.

Der verwendete Befehl sah beispielsweise so aus:

rsync -rlt --partial --info=progress2 \
"/media/user/ALTE_PLATTE/Verzeichnis" \
"/mnt/NEUE_PLATTE/Ziel/"

---

Nicht sofort das Dateisystem reparieren

Die auftretenden Fehler waren:

Input/output error (5)

Deshalb wurde zunächst nicht versucht, die alte NTFS-Platte zu reparieren.

Stattdessen wurde ihr SMART-Zustand untersucht:

sudo smartctl -a /dev/sdX

Dort zeigten sich zahlreiche:

Reallocated_Sector_Ct
Current_Pending_Sector
Offline_Uncorrectable

Damit war klar:

Die Ursache war nicht nur ein harmloser Kopierfehler, sondern die Platte selbst war physisch problematisch.

---

Erst alles Lesbare kopieren

Der weitere Ablauf war:

rsync kopiert alles noch Lesbare
        ↓
Liste der tatsächlich fehlgeschlagenen Dateien
        ↓
keine erneute Komplettkopie
        ↓
nur Problemdateien separat retten

Für die problematischen Einzeldateien wurde anschließend GNU ddrescue verwendet.

Beispiel:

ddrescue -n quelle ziel ziel.ddrescue.map
ddrescue -r3 quelle ziel ziel.ddrescue.map

Damit konnten mehrere Dateien gerettet werden, die rsync zuvor nicht mehr erfolgreich übertragen konnte.

---

Warum das sinnvoller war als ein Komplett-Image

Im konkreten Fall war der weit überwiegende Teil der Platte noch lesbar.

Deshalb wurde zuerst mit rsync kopiert und ddrescue anschließend nur für die wenigen Problemdateien eingesetzt.

Das vermied einen vollständigen zusätzlichen Lesedurchlauf über die bereits angeschlagene Festplatte.

Für einen anderen Schadensfall kann ein vollständiges sektorweises Abbild sinnvoll sein.

Hier war es aber nicht notwendig, weil die relevanten Daten weitgehend noch dateibasiert lesbar waren.

---

Praktischer Ablauf

Bei einem ähnlichen Fall würde ich anhand dieser Erfahrung so vorgehen:

1. Daten mit rsync kopieren
2. Fehlerausgabe sichern
3. nicht aufgrund von Code 23 alles verwerfen
4. endgültig fehlgeschlagene Dateien identifizieren
5. SMART prüfen
6. bei Hardwarefehlern keine unnötigen Komplettläufe mehr
7. Problemdateien gezielt mit ddrescue bearbeiten

---

Fazit

rsync Exit-Code 23 bedeutet:

Nicht alles konnte übertragen werden.

Er bedeutet aber nicht:

Die komplette Sicherung ist unbrauchbar.

Gerade bei einer sterbenden Festplatte kann rsync noch einen sehr großen Teil der Daten erfolgreich sichern.

Die sinnvollere Strategie war in diesem Fall:

erst alles noch Lesbare normal kopieren und anschließend nur die tatsächlich fehlgeschlagenen Dateien gezielt retten.

Eine zusätzliche SSD ist unter Linux schnell formatiert. Damit sie aber nach jedem Neustart zuverlässig am gleichen Ort verfügbar ist und auch im Dateimanager auftaucht, lohnt sich ein sauberer Eintrag in /etc/fstab.

In meinem Fall sollte eine zuvor anderweitig verwendete SSD dauerhaft als Linux-Datenplatte eingebunden werden.

Das Ergebnis:

ext4
fester Mountpoint
Einbindung über UUID
kein Bootabbruch bei fehlender Platte
Anzeige im Dateimanager

Ausgangslage

Die SSD war bereits als ext4 formatiert und hatte ein eigenes Label erhalten.

Mit

lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINTS

ließen sich Dateisystem, Label und UUID anzeigen.

Beispielsweise:

sdb1
ext4
DatenSSD
12f74ace-32c3-4947-8da2-e98697034c0a

Die UUID ist dabei wichtiger als der Gerätename.

---

Warum nicht einfach /dev/sdb1 verwenden?

Gerätenamen wie

/dev/sda1
/dev/sdb1
/dev/sdc1

können sich ändern.

Welche Platte beim Start welchen Buchstaben erhält, sollte deshalb nicht die Grundlage für einen dauerhaften Mount sein.

Eine UUID identifiziert dagegen das Dateisystem selbst.

Deshalb wurde die Platte in /etc/fstab über ihre UUID eingetragen.

---

1. Mountpoint anlegen

Die Datenplatte sollte dauerhaft unter einem Verzeichnis innerhalb von /mnt erreichbar sein.

Beispiel:

sudo mkdir -p /mnt/daten

Der Name ist frei wählbar.

---

2. UUID ermitteln

Die benötigte UUID lässt sich beispielsweise mit lsblk anzeigen:

lsblk -o NAME,FSTYPE,LABEL,UUID,MOUNTPOINTS

Entscheidend ist die UUID der gewünschten ext4-Partition.

---

3. /etc/fstab ergänzen

Der verwendete Eintrag hatte folgendes Schema:

UUID=12f74ace-32c3-4947-8da2-e98697034c0a /mnt/daten ext4 defaults,nofail,x-gvfs-show 0 2

Natürlich muss die UUID durch die UUID des eigenen Dateisystems ersetzt werden.

Die Felder bedeuten:

UUID=...

Das einzubindende Dateisystem.

/mnt/daten

Der gewünschte Mountpoint.

ext4

Das verwendete Dateisystem.

defaults

Normale Standard-Mountoptionen.

nofail

Der Rechner soll weiterhin booten können, wenn die Platte einmal nicht verfügbar ist.

x-gvfs-show

Das Laufwerk soll von GVfs-basierten Desktop-Dateimanagern angezeigt werden.

0 2

Die üblichen Werte für Dump und Dateisystemprüfung eines zusätzlichen ext4-Datenträgers.

---

4. systemd über die Änderung informieren

Nach einer Änderung an /etc/fstab wurde ausgeführt:

sudo systemctl daemon-reload

Damit werden die aus /etc/fstab generierten Mount-Units neu eingelesen.

---

5. Mount testen

Nach der Einrichtung sollte kontrolliert werden, ob die Partition tatsächlich am vorgesehenen Ort hängt.

Zum Beispiel:

findmnt /mnt/daten

oder:

lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINTS

Der gewünschte Mountpoint sollte jetzt bei der Partition erscheinen.

---

Warum nofail sinnvoll ist

Ohne nofail kann eine in /etc/fstab eingetragene, aber nicht verfügbare Datenplatte den Bootvorgang unnötig verzögern oder Probleme verursachen.

Bei einer zusätzlichen Datenplatte bestand dafür kein Grund.

Deshalb:

nofail

Das Root-Dateisystem gehört natürlich in eine andere Kategorie.

---

Warum x-gvfs-show?

Ein Mount unter

/mnt/daten

ist technisch auch ohne x-gvfs-show verfügbar.

Für einen Desktop-Rechner ist es aber praktisch, wenn das Laufwerk zusätzlich im Dateimanager erscheint.

Dafür wurde verwendet:

x-gvfs-show

---

lost+found ist normal

Nach der Einrichtung einer ext4-Partition erschien im Wurzelverzeichnis:

lost+found

Das ist kein Überbleibsel alter Dateien und kein Fehler.

lost+found gehört zu ext-Dateisystemen und kann von Dateisystemprüfungen verwendet werden, um gefundene, aber nicht mehr korrekt zuordenbare Dateisystemobjekte abzulegen.

Der Ordner sollte einfach bleiben.

---

Fertiger fstab-Eintrag

Das verwendete Muster lautet:

UUID=DEINE-UUID /mnt/daten ext4 defaults,nofail,x-gvfs-show 0 2

Danach:

sudo systemctl daemon-reload

und anschließend kontrollieren:

findmnt /mnt/daten

---

Fazit

Für eine zusätzliche interne Linux-Datenplatte hat sich diese Kombination bewährt:

ext4
+
UUID statt /dev/sdX
+
fester Mountpoint unter /mnt
+
nofail
+
x-gvfs-show

Damit ist die Platte nach dem Start zuverlässig am gleichen Pfad verfügbar, ohne dass ein wechselnder Gerätename wie /dev/sdb1 relevant wird.

Und sie bleibt trotzdem komfortabel im Desktop-Dateimanager sichtbar.

Wer von Windows auf Linux umgestiegen ist, kennt das Problem: Im Rechner steckt noch eine alte SSD oder Festplatte mit NTFS-Partitionen und vielleicht sogar einer kleinen Partition namens System-reserviert.

Bevor man sie löscht und als Linux-Datenträger weiterverwendet, sollte man eindeutig klären:

Bootet das aktuelle Linux wirklich von einem anderen Datenträger?

Genau diese Prüfung war in meinem Fall notwendig, bevor eine alte Windows-SSD vollständig neu verwendet werden konnte.

Das Problem

Auf dem Rechner waren mehrere Laufwerke vorhanden:

• eine NVMe-SSD mit dem aktuellen Linux-System
• eine weitere SSD mit Daten
• eine ältere SSD mit ehemaligen Windows-Partitionen
• eine zusätzliche alte NTFS-Festplatte

Die frühere Windows-SSD enthielt unter anderem:

System-reserviert
Datensicherung

Die Bezeichnung System-reserviert ist ein guter Grund, nicht einfach alles zu löschen.

Zuerst musste geklärt werden, ob diese Partition noch irgendeine Rolle für den aktuellen Bootvorgang spielte.

---

1. Alle Datenträger anzeigen

Eine übersichtliche Darstellung liefert:

lsblk -e7 -o NAME,PATH,SIZE,MODEL,FSTYPE,LABEL,PARTLABEL,UUID,MOUNTPOINTS

Interessant sind vor allem:

NAME
MODEL
FSTYPE
LABEL
UUID
MOUNTPOINTS

So lässt sich zunächst unterscheiden:

• Welche Platte enthält Linux?
• Welche Partition ist als / eingehängt?
• Welche Platte enthält noch NTFS?
• Gibt es alte Windows-Systempartitionen?

Zusätzlich kann man die Partitionstabellen ansehen:

sudo fdisk -l

Bei mehreren ähnlich großen SSDs ist die Modellbezeichnung besonders hilfreich.

---

2. Prüfen, wo das Root-Dateisystem liegt

Entscheidend ist zunächst die Linux-Systempartition:

findmnt -no SOURCE,FSTYPE,TARGET /

Eine typische Ausgabe könnte beispielsweise so aussehen:

/dev/nvme0n1p5 ext4 /

Damit ist klar:

Das laufende Linux befindet sich auf dieser Partition.

Das sagt allerdings noch nicht zwingend, wo die für den UEFI-Boot benötigte EFI-Systempartition liegt.

---

3. EFI-Partition prüfen

Bei einem UEFI-System:

findmnt /boot/efi

Damit lässt sich feststellen, welches Gerät aktuell unter

/boot/efi

eingehängt ist.

Im konkreten Fall lag auch die EFI-Partition auf derselben NVMe-SSD wie das aktuelle Linux-System.

Damit sprach bereits sehr viel dafür, dass die alte Windows-SSD nicht mehr zum Booten benötigt wurde.

---

4. UEFI-Boot-Einträge kontrollieren

Zur zusätzlichen Absicherung:

sudo efibootmgr -v

efibootmgr zeigt die im UEFI gespeicherten Boot-Einträge.

Interessant sind insbesondere:

BootCurrent
BootOrder

und die Gerätepfade der einzelnen Boot-Einträge.

Im untersuchten System zeigte der aktive Linux-Boot-Eintrag auf die EFI-Partition der NVMe-SSD.

Die alte Windows-SSD tauchte dort nicht als benötigter aktueller Boot-Datenträger auf.

---

5. /etc/fstab kontrollieren

Eine weitere wichtige Kontrolle:

grep -Ev '^\s*#|^\s*$' /etc/fstab

Damit werden Kommentare und Leerzeilen ausgeblendet.

In meinem Fall enthielt /etc/fstab Einträge für:

• die Linux-Systempartition
• die EFI-Partition
• einen zusätzlichen Linux-Datenträger

Die alte Windows-SSD war dort nicht eingebunden.

Auch das bestätigte:

Das laufende System war nicht auf sie angewiesen.

---

6. Erst danach löschen

Die Kombination aus

lsblk
findmnt
efibootmgr
/etc/fstab

lieferte schließlich ein konsistentes Bild:

Linux-System
      ↓
NVMe-SSD

EFI-Systempartition
      ↓
dieselbe NVMe-SSD

aktiver UEFI-Boot-Eintrag
      ↓
EFI-Partition der NVMe-SSD

alte Windows-SSD
      ↓
weder Root noch EFI noch fstab-Abhängigkeit

Erst danach wurde die alte Windows-Partitionierung entfernt und die SSD als Linux-Datenträger neu eingerichtet.

---

Warum die Prüfung wichtig ist

Eine kleine Partition mit Namen wie

System-reserviert
EFI System
Boot
Recovery

sollte man nicht allein aufgrund ihres Alters löschen.

Gerade Rechner, auf denen Windows und Linux nacheinander oder parallel installiert waren, können Boot-Dateien auf einem anderen Laufwerk enthalten als das eigentliche Betriebssystem.

Das Betriebssystem kann also beispielsweise auf

/dev/nvme0n1

liegen, während der Rechner theoretisch trotzdem eine EFI-Partition auf

/dev/sda

verwenden könnte.

Deshalb ist es sinnvoll, nicht nur das Root-Dateisystem zu prüfen.

---

Minimaler Prüfablauf

Vor dem Löschen eines alten Systemdatenträgers würde ich mindestens diese vier Prüfungen durchführen:

lsblk -e7 -o NAME,PATH,SIZE,MODEL,FSTYPE,LABEL,UUID,MOUNTPOINTS

findmnt -no SOURCE,FSTYPE,TARGET /

findmnt /boot/efi

sudo efibootmgr -v

Zusätzlich:

grep -Ev '^\s*#|^\s*$' /etc/fstab

Wenn alle Ergebnisse eindeutig auf einen anderen Datenträger zeigen, ist die Grundlage vorhanden, die alte Platte anschließend neu zu verwenden.

---

Fazit

Der gefährliche Teil beim Wiederverwenden einer alten Windows-SSD ist nicht das Formatieren selbst.

Der gefährliche Teil ist die Frage:

Bin ich wirklich sicher, dass mein Rechner sie nicht mehr zum Booten benötigt?

Mit

lsblk
findmnt
efibootmgr
fstab

lässt sich diese Frage unter Linux relativ zuverlässig beantworten.

Erst wenn Root-Dateisystem, EFI-Partition, UEFI-Boot-Eintrag und dauerhafte Mounts eindeutig geklärt sind, sollte eine alte Windows-Systempartition entfernt werden.

Nach einem fehlgeschlagenen Joomla-Update kann es naheliegend sein, einfach ein wenige Tage altes Backup zurückzuspielen. Das funktioniert jedoch nicht immer so sauber, wie man erwarten würde.

In meinem Fall war zuvor ein Update von Joomla 5.2.5 auf Joomla 5.4.x erfolgt. Nachdem anschließend Probleme mit einer Erweiterung auftraten, wurde ein Backup des älteren Joomla-5.2.5-Stands wiederhergestellt.

Danach funktionierte das Joomla-Backend wieder, das Frontend jedoch nicht. Stattdessen erschien:

Call to undefined method Joomla\Module\Menu\Site\Helper\MenuHelper::getItems()

Das Problem

Der Fehler deutet zunächst auf das Joomla-Menümodul beziehungsweise dessen PHP-Klassen hin.

Auffällig war jedoch der zeitliche Zusammenhang:

1. Joomla 5.2.5 funktionierte.
2. Das System wurde auf Joomla 5.4.x aktualisiert.
3. Danach traten Probleme auf.
4. Ein Backup des vorherigen Joomla-5.2.5-Stands wurde über die bestehende Installation zurückgespielt.
5. Backend-Zugriff war wieder möglich, das Frontend erzeugte jedoch den MenuHelper::getItems()-Fehler.

Damit lag der Verdacht nahe, dass nicht die komplette Installation wieder exakt auf den alten Zustand zurückgesetzt worden war.

Ursache: Ein Restore löscht nicht automatisch alle vorhandenen Dateien

Der wichtige Punkt ist, wie ein typischer Joomla-Backup-Restore funktioniert.

Beim Wiederherstellen werden Dateien aus dem Backup auf den Server geschrieben. Vorhandene Dateien mit demselben Namen werden dabei ersetzt.

Dateien, die bereits auf dem Server liegen, aber im Backup nicht vorkommen, werden dagegen nicht zwangsläufig gelöscht.

Das ist grundsätzlich sinnvoll. Ein Restore kann schließlich nicht sicher wissen, ob zusätzliche Dateien:

• zu einer neueren Softwareversion gehören,
• bewusst manuell abgelegt wurden,
• von einer Erweiterung stammen,
• oder aus anderen Gründen erhalten bleiben sollen.

Ein Restore ist deshalb nicht automatisch mit einer vollständigen Synchronisation des Dateisystems auf den Zustand des Backups gleichzusetzen.

Warum das bei Joomla-Versionen problematisch werden kann

Bei einem Joomla-Update können sich nicht nur Inhalte bestehender Dateien ändern.

Zwischen Joomla-Versionen können auch Dateien:

• neu hinzukommen,
• verschoben werden,
• umbenannt werden,
• oder vollständig entfallen.

Wird anschließend ein Backup einer älteren Joomla-Version über diesen neueren Stand zurückgespielt, entsteht deshalb möglicherweise ein Mischzustand:

Joomla 5.2.5 aus dem Backup
+
übrig gebliebene Dateien aus Joomla 5.4.x
=
potenziell inkonsistente Installation

Das war in diesem Fall die naheliegende Erklärung für den Methodenfehler im Frontend.

Wichtig ist die Unterscheidung:

Gesichert ist, dass ein Restore zusätzliche vorhandene Dateien nicht zwingend entfernt und dadurch nach einem Versionswechsel Dateireste bestehen bleiben können.

Nicht abschließend nachgewiesen wurde, welche konkrete verbliebene Datei den MenuHelper::getItems()-Fehler ausgelöst hatte.

Lösung: Joomla-Dateien vor dem Restore bereinigen

Statt das ältere Backup noch einmal einfach über die vorhandene Installation zu schreiben, sollte zunächst der bestehende Joomla-Core entfernt werden.

Vorher sollte selbstverständlich ein Rückfallpunkt vorhanden sein. Bei einem VPS kann dafür beispielsweise ein Snapshot verwendet werden.

Ein Snapshot eignet sich gut, um den kompletten Serverzustand vor solchen Änderungen kurzfristig wiederherstellen zu können. Er ersetzt allerdings nicht grundsätzlich ein dauerhaftes und extern verfügbares Backup.

Joomla-Core-Verzeichnisse entfernen

Vor dem erneuten Restore können insbesondere die Joomla-Core-Verzeichnisse entfernt werden:

administrator
api
cli
components
includes
language
layouts
libraries
media
modules
plugins
templates

Außerdem gehören zentrale Joomla-Dateien dazu, beispielsweise:

configuration.php
index.php

Danach wird das Backup erneut in das nun bereinigte Webverzeichnis eingespielt.

Achtung bei eigenen Dateien

Die Liste darf nicht blind auf jede Installation angewendet werden.

Vor dem Löschen muss geprüft werden, ob sich in diesen Verzeichnissen eigene Dateien oder nicht anderweitig gesicherte Inhalte befinden.

Das gilt insbesondere für:

media
templates

Dort können je nach Installation beispielsweise eigene Medien, Template-Anpassungen oder zusätzliche Dateien liegen.

Der entscheidende Punkt ist daher nicht:

Lösche immer exakt diese Verzeichnisse.

Sondern:

Stelle sicher, dass vor dem Restore keine Dateien einer anderen Joomla-Version im Zielsystem zurückbleiben.

Datenbank beim Restore

Auch die Datenbank sollte zum Backup-Zustand passen.

Beim Restore sollte derselbe Tabellenpräfix verwendet werden wie in der gesicherten Joomla-Installation.

Wenn das verwendete Restore-Werkzeug die Möglichkeit bietet, vorhandene Tabellen mit demselben Präfix vor dem Import zu entfernen, verhindert das ebenfalls einen Mischstand aus alter und neuer Installation.

Dateisystem und Datenbank sollten nach dem Restore gemeinsam zum selben Sicherungszeitpunkt gehören.

Optional: Joomla-Autoload-Cache neu erzeugen

Falls anschließend weiterhin Fehler auftreten, bei denen Namespaces oder Joomla-Klassen offenbar nicht zum Dateibestand passen, kann zusätzlich der Joomla-Autoload-Cache relevant sein.

Die entsprechende Cache-Datei liegt unter:

administrator/cache/autoload_psr4.php

Sie kann gelöscht werden, damit Joomla sie neu erzeugt.

Das ist jedoch ein zusätzlicher Reparaturschritt und ersetzt nicht die Bereinigung eines tatsächlich inkonsistenten Dateibestands.

Warum einfaches „Backup drüberspielen“ nicht genügt

Der entscheidende Unterschied ist:

Restore:
Backup-Dateien auf das vorhandene Dateisystem schreiben

ist nicht zwingend dasselbe wie:

Rollback:
Das gesamte Dateisystem exakt auf einen früheren Zustand zurücksetzen

Ein VPS-Snapshot kommt dem zweiten Fall deutlich näher, weil dabei der komplette gespeicherte Systemzustand zurückgesetzt wird.

Ein Joomla-Backup-Restore arbeitet dagegen innerhalb des vorhandenen Dateisystems. Deshalb können Dateien überleben, die zum Zeitpunkt des Backups noch gar nicht existierten.

Ergebnis

Für fehlgeschlagene Joomla-Updates ergibt sich daraus ein wichtiger Grundsatz:

Wenn ein Backup einer älteren Joomla-Version nach einem Update wiederhergestellt werden soll, sollte man vermeiden, es einfach über den neueren Dateibestand zu entpacken.

Sicherer ist:

1. Rückfallpunkt erstellen.
2. Eigene Dateien und Anpassungen sichern beziehungsweise identifizieren.
3. Vorhandenen Joomla-Core bereinigen.
4. Backup wiederherstellen.
5. Datenbank auf denselben Sicherungsstand bringen.
6. Frontend und Backend testen.
7. Bei Namespace-Problemen gegebenenfalls den Joomla-Autoload-Cache neu erzeugen.

Ein Fehler wie

Call to undefined method Joomla\Module\Menu\Site\Helper\MenuHelper::getItems()

muss damit nicht zwangsläufig bedeuten, dass das Menümodul selbst defekt ist.

Nach einem Restore über eine andere Joomla-Version hinweg sollte auch geprüft werden, ob schlicht Dateien unterschiedlicher Joomla-Versionen miteinander vermischt wurden.

Eine Joomla-Installation, die über viele Jahre betrieben und immer wieder erweitert wurde, sammelt mit der Zeit einiges an Ballast an. Erweiterungen werden installiert, ausprobiert und irgendwann wieder deinstalliert. Manche hinterlassen Datenbanktabellen, andere Dateien im Dateisystem. Gleichzeitig können Tabellen wie die Session-Tabelle über Jahre massiv anwachsen, wenn die automatische Bereinigung nicht zuverlässig funktioniert.

Dieser Artikel beschreibt einen praktischen Weg, um eine gewachsene Joomla-Installation schrittweise zu untersuchen und aufzuräumen.

Wichtig: Vor Änderungen an der Datenbank sollte immer ein aktuelles Backup vorhanden sein.

Das Problem

Bei einer älteren Joomla-Installation fiel auf, dass die Datenbank ungewöhnlich groß geworden war. Gleichzeitig zeigte der Joomla-Bereich System → Discover mehr als hundert Erweiterungen an, obwohl viele davon längst nicht mehr bewusst genutzt wurden.

Die Fragen waren deshalb:

• Welche Tabellen belegen besonders viel Speicher?
• Welche Tabellen gehören zum Joomla-Core?
• Welche stammen von noch installierten Erweiterungen?
• Welche sind wahrscheinlich Reste längst deinstallierter Erweiterungen?
• Was bedeutet die lange Liste unter „Discover“?
• Können temporäre Dateien im Joomla-Verzeichnis gelöscht werden?

Statt sofort Tabellen zu löschen, lohnt sich zunächst eine Bestandsaufnahme.

---

1. Datenbanktabellen nach Größe untersuchen

Für eine erste Analyse braucht man nicht zwingend einen kompletten SQL-Dump mit allen Inhalten. Oft genügt eine Übersicht der Tabellen einschließlich Größe und ungefährer Zeilenzahl.

In phpMyAdmin kann innerhalb der betreffenden Datenbank folgende Abfrage ausgeführt werden:

SELECT
  table_name AS Tabelle,
  engine AS Engine,
  table_rows AS Zeilen,
  ROUND((data_length + index_length) / 1024 / 1024, 2) AS Groesse_MB,
  create_time AS Erstellt,
  update_time AS Letzte_Aenderung
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC;

Das Ergebnis lässt sich beispielsweise als CSV exportieren.

Die Abfrage liefert unter anderem:

• Tabellenname
• verwendete Storage Engine
• ungefähre Anzahl der Datensätze
• Größe von Daten und Indizes
• Erstellungs- und Änderungszeitpunkte, soweit verfügbar

Bei InnoDB ist die angegebene Zeilenzahl nicht zwingend exakt. Für eine erste Größenanalyse reicht sie aber aus.

---

2. Eine extrem große Joomla-Session-Tabelle

Besonders auffällig kann die Joomla-Tabelle

#__session

werden.

In dem untersuchten Fall enthielt sie mehr als vier Millionen Datensätze und belegte mehrere Gigabyte.

Dabei handelt es sich nicht um einen Datei- oder Bildcache.

Die Session-Tabelle speichert Sitzungsinformationen. Dazu gehören beispielsweise anonyme Besucher-Sessions und Sitzungen eingeloggter Benutzer beziehungsweise Administratoren.

Bilder, CSS-Dateien oder andere Mediendateien liegen dort nicht.

Alte Sessions zählen

Zunächst kann geprüft werden, wie viele Einträge älter als sieben Tage sind:

SELECT COUNT(*) AS aelter_7_tage
FROM #__session
WHERE `time` < UNIX_TIMESTAMP(NOW() - INTERVAL 7 DAY);

Der Präfix #__ muss dabei durch den tatsächlichen Tabellenpräfix der Joomla-Installation ersetzt werden.

Zusätzlich kann die Gesamtzahl ermittelt werden:

SELECT COUNT(*) AS gesamt
FROM #__session;

Im Praxisfall waren nahezu sämtliche Einträge älter als sieben Tage. Die Tabelle bestand damit fast vollständig aus alten Sessions.

---

3. Alte Session-Daten löschen

Eine vorsichtige Möglichkeit besteht darin, alte Einträge portionsweise zu löschen:

DELETE FROM #__session
WHERE `time` < UNIX_TIMESTAMP(NOW() - INTERVAL 7 DAY)
ORDER BY `time`
LIMIT 100000;

Bei mehreren Millionen Datensätzen kann das allerdings sehr lange dauern.

Im konkreten Fall benötigte bereits das Löschen von 100.000 Datensätzen deutlich mehr als zwei Minuten. Auch größere Blöcke machten die Bereinigung entsprechend langwierig.

Alternative: Session-Tabelle vollständig leeren

Wenn die Website keine angemeldeten Frontend-Benutzer hat und es akzeptabel ist, dass momentan angemeldete Administratoren ihre Sitzung verlieren, kann die Session-Tabelle auch vollständig geleert werden:

TRUNCATE TABLE #__session;

Das ist erheblich schneller als Millionen einzelne Datensätze mit DELETE zu entfernen.

Die Folge ist:

• bestehende Sessions gehen verloren,
• Administratoren müssen sich gegebenenfalls neu anmelden,
• Dateien, Bilder und Inhalte werden nicht gelöscht.

Für eine reine Session-Tabelle kann das bei einer Wartung eine sinnvolle Lösung sein.

---

4. Warum bleiben nach einer Joomla-Deinstallation Tabellen übrig?

Bei älteren Joomla-Installationen finden sich häufig Tabellen von Erweiterungen, die längst nicht mehr verwendet werden.

Eine Deinstallation entfernt nicht zwangsläufig alle Daten.

Ob Datenbanktabellen beim Entfernen einer Erweiterung ebenfalls gelöscht werden, hängt davon ab, wie die jeweilige Erweiterung ihre Deinstallation implementiert.

Deshalb können über Jahre komplette Tabellenfamilien zurückbleiben.

Typisch sind Namen wie:

#__extensionname
#__extensionname_files
#__extensionname_statistics
#__extensionname_categories
#__extensionname_config

Solche Tabellen sollte man allerdings nicht allein aufgrund ihres Namens löschen.

Zunächst muss geklärt werden, ob die zugehörige Erweiterung noch installiert ist.

---

5. Prüfen, ob eine Erweiterung noch installiert ist

Joomla führt installierte Erweiterungen in der Tabelle

#__extensions

Eine einfache Abfrage kann beispielsweise so aussehen:

SELECT
  extension_id,
  name,
  type,
  element,
  folder,
  enabled
FROM #__extensions
ORDER BY name, type;

Bei einer bestimmten Erweiterung kann gezielter gesucht werden:

SELECT
  extension_id,
  name,
  type,
  element,
  folder,
  enabled
FROM #__extensions
WHERE LOWER(CONCAT_WS(' ', name, type, element, folder))
      REGEXP 'name-der-erweiterung';

Das ermöglicht eine wichtige Unterscheidung:

Erweiterung noch installiert

Dann sollten die zugehörigen Tabellen nicht einfach gelöscht werden.

Auch eine deaktivierte Erweiterung kann weiterhin vollständig installiert sein.

Erweiterung nicht mehr installiert

Existieren trotzdem noch passende Datenbanktabellen, handelt es sich sehr wahrscheinlich um Altlasten.

Vor dem Löschen sollte trotzdem geprüft werden, ob die Daten noch benötigt werden.

Manche Tabellen enthalten nicht nur Konfiguration, sondern tatsächliche Inhalte, Formulareingaben, Statistiken oder Dokumentinformationen.

---

6. Tabellen einer alten Erweiterung löschen

Ist eindeutig geklärt, dass eine Erweiterung nicht mehr verwendet wird und ihre Daten ebenfalls nicht mehr benötigt werden, können die verbliebenen Tabellen entfernt werden.

Die vorhandenen Tabellen lassen sich zunächst anzeigen:

SHOW TABLES LIKE '%extensionname%';

Eine nützliche Variante erzeugt zunächst nur die passenden DROP TABLE-Befehle:

SELECT CONCAT(
  'DROP TABLE `',
  table_name,
  '`;'
) AS drop_sql
FROM information_schema.tables
WHERE table_schema = DATABASE()
  AND table_name LIKE '%extensionname%';

Die erzeugten Befehle können anschließend überprüft werden.

Erst danach sollte tatsächlich gelöscht werden.

Beispiel:

DROP TABLE IF EXISTS
  `prefix_extensionname`,
  `prefix_extensionname_files`,
  `prefix_extensionname_statistics`;

Das ist sicherer, als Tabellen anhand eines vermuteten Namensschemas automatisch zu entfernen.

---

7. Nicht jede große Tabelle ist eine Altlast

Eine wichtige Erkenntnis bei solchen Aufräumarbeiten:

Große Tabellen sind nicht automatisch überflüssig.

Zu Joomla selbst gehören beispielsweise Tabellenfamilien für Funktionen wie:

#__finder_*
#__redirect_links
#__action_logs*
#__workflow_*
#__scheduler_*
#__guidedtours*
#__history

Auch installierte Drittanbieter-Erweiterungen können große Tabellen besitzen, etwa für:

• Statistiken
• Revisionen
• Suchindizes
• Formulardaten
• Dateiverwaltung
• Protokolle

Solche Tabellen sollten nicht entfernt werden, solange die zugehörige Funktion oder Erweiterung noch verwendet wird.

Hier ist gegebenenfalls eine Bereinigung der Inhalte sinnvoller als das Löschen der gesamten Tabelle.

---

8. Was bedeutet „Discover“ in Joomla?

Unter

System → Discover

kann Joomla Erweiterungen anzeigen, die im Dateisystem gefunden werden, aber nicht regulär als installierte Erweiterungen registriert sind.

Das ist etwas anderes als eine übrig gebliebene Datenbanktabelle.

Ein Discover-Eintrag bedeutet im Kern:

Joomla findet Dateien einer Erweiterung, aber der entsprechende Installationszustand passt nicht dazu.

Solche Reste können beispielsweise in Verzeichnissen liegen wie:

administrator/components/
components/
plugins/
modules/
administrator/modules/

Das erklärt auch, warum eine längst deinstallierte Erweiterung weiterhin unter „Discover“ auftauchen kann.

Ihre Datenbanktabellen können bereits verschwunden sein, während Teile der Erweiterung noch auf dem Webserver liegen.

---

9. Discover-Einträge bereinigen

Ein Discover-Eintrag sollte nicht einfach blind entfernt werden.

Zunächst muss geklärt werden:

1. Wird die Erweiterung noch verwendet?
2. Ist sie regulär installiert?
3. Handelt es sich tatsächlich nur um übrig gebliebene Dateien?

Wenn eindeutig feststeht, dass die Erweiterung nicht mehr gebraucht wird, können die zugehörigen Dateireste entfernt werden.

Dabei reicht es nicht immer, nur

administrator/components/com_beispiel

zu löschen.

Eine Erweiterung kann zusätzlich Dateien in weiteren Bereichen besitzen, beispielsweise:

components/com_beispiel
plugins/...
modules/...
administrator/modules/...

Nach dem Entfernen der verbliebenen Erweiterungsdateien sollte Joomla sie bei einer erneuten Discover-Suche nicht mehr erkennen.

Datenbankreste und Discover-Einträge sind damit zwei getrennte Baustellen:

• alte Tabellen → Datenbank
• Discover-Einträge → meist übrig gebliebene Dateien beziehungsweise ein inkonsistenter Installationszustand

---

10. Was kann aus dem Joomla-tmp-Verzeichnis gelöscht werden?

Auch im Joomla-Verzeichnis

tmp/

können sich über Jahre Dateien ansammeln.

Joomla verwendet dieses Verzeichnis als temporären Arbeitsbereich, unter anderem bei Installationen und Updates von Erweiterungen.

Dort können beispielsweise liegen:

• heruntergeladene Installationsarchive,
• entpackte Erweiterungen,
• Reste abgebrochener Installationen,
• andere temporäre Dateien.

Alte Inhalte dieses Verzeichnisses können in der Regel entfernt werden, wenn gerade

• kein Joomla-Update,
• keine Erweiterungsinstallation,
• kein Restore
• und kein anderer Wartungsvorgang

läuft.

Der Ordner tmp selbst sollte dagegen bestehen bleiben.

Auch sollte der konfigurierte tmp-Pfad nicht verändert werden, wenn die Installation korrekt funktioniert.

---

11. Sinnvolle Reihenfolge beim Aufräumen

Für eine ältere Joomla-Installation hat sich folgende Reihenfolge als übersichtlich erwiesen:

1. Backup erstellen

Vor Änderungen an Datenbank oder Dateisystem.

2. Tabellen nach Größe analysieren

Mit information_schema.tables.

3. Extrem große technische Tabellen untersuchen

Zum Beispiel #__session.

4. Installationsstatus von Erweiterungen prüfen

Über #__extensions.

5. Verwaiste Datenbanktabellen identifizieren

Nur löschen, wenn die Erweiterung sicher nicht mehr benötigt wird.

6. Joomla „Discover“ kontrollieren

Übrig gebliebene Erweiterungsdateien identifizieren.

7. Dateireste entfernen

Dabei alle zugehörigen Erweiterungspfade berücksichtigen.

8. tmp bereinigen

Nur alte temporäre Inhalte entfernen, nicht den Ordner selbst.

---

Ergebnis

Bei einer über Jahre gewachsenen Joomla-Installation lohnt sich ein systematisches Aufräumen.

Der größte Speicherverbrauch muss dabei nicht einmal von alten Erweiterungen kommen. Im beschriebenen Praxisfall war zunächst die Session-Tabelle das deutlichste Problem: Millionen alter Sessions hatten sich angesammelt.

Gleichzeitig zeigte die Analyse, dass zwischen verschiedenen Arten von Altlasten unterschieden werden muss:

• alte Session-Daten,
• Tabellen deinstallierter Erweiterungen,
• Tabellen weiterhin installierter Erweiterungen,
• Dateireste im Joomla-Dateisystem,
• Discover-Einträge,
• temporäre Dateien.

Wer diese Bereiche getrennt betrachtet und Änderungen jeweils vorher überprüft, kann eine alte Joomla-Installation erheblich aufräumen, ohne dabei versehentlich noch verwendete Komponenten oder Daten zu entfernen.

Eine Joomla-Datenbank mit mehreren Gigabyte Größe ist zumindest ein Anlass, genauer hinzusehen. In meinem Fall war eine Joomla-Installation mit MariaDB auf rund 3,65 GB angewachsen. Bei der Analyse fiel insbesondere die Session-Tabelle auf.

Dieser Artikel dokumentiert die Schritte, mit denen sich eine solche Tabelle untersuchen und bereinigen lässt. Wichtig: Vor Änderungen an einer produktiven Datenbank sollte immer ein vollständiges Backup vorhanden sein.

Problem: Eine ungewöhnlich große Joomla-Datenbank

Der erste Schritt besteht nicht darin, auf Verdacht Tabellen oder Datensätze zu löschen. Zunächst sollte geklärt werden, welche Tabellen den Speicher tatsächlich belegen.

Mit dieser Abfrage lassen sich die Tabellen einer Datenbank nach ihrer Größe sortieren:

SELECT
    table_name,
    ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_in_mb
FROM information_schema.tables
WHERE table_schema = 'DATENBANKNAME'
ORDER BY size_in_mb DESC;

DATENBANKNAME muss durch den tatsächlichen Namen der Joomla-Datenbank ersetzt werden.

In meinem Fall gehörte die Joomla-Session-Tabelle zu den auffälligen Tabellen.

Die Joomla-Session-Tabelle untersuchen

Joomla verwendet ein individuell konfiguriertes Tabellenpräfix. Aus einer Tabelle wie

abc_session

kann daher bei einer anderen Installation beispielsweise

xyz_session

werden.

Die Struktur lässt sich mit DESCRIBE anzeigen:

DESCRIBE `abc_session`;

In der untersuchten Joomla-Installation hatte die Session-Tabelle unter anderem folgende Felder:

session_id
client_id
guest
time
data
userid
username

Für die weitere Analyse sind vor allem time und data interessant.

time ist ein Integer-Feld, über das sich alte Session-Einträge identifizieren lassen. data ist ein MEDIUMTEXT-Feld und kann entsprechend umfangreiche Session-Daten enthalten.

Wie groß sind die eigentlichen Session-Daten?

Um zunächst nur die gespeicherten Inhalte des Feldes data zu untersuchen, kann man deren Gesamtlänge ermitteln:

SELECT
    SUM(CHAR_LENGTH(data)) AS total_data_size
FROM `abc_session`;

In meinem Fall ergab die Abfrage:

687078044

CHAR_LENGTH() liefert hier die Anzahl der Zeichen, nicht unmittelbar die physische Größe der Tabelle auf dem Datenträger. Bei den vorliegenden Session-Daten entsprach die Größenordnung dennoch bereits mehreren hundert Megabyte Inhalt allein in diesem Feld.

Die tatsächliche Tabellengröße sollte deshalb zusätzlich über information_schema.tables bzw. die Tabelleninformationen von phpMyAdmin kontrolliert werden.

Wie viele alte Sessions gibt es?

Bevor Daten gelöscht werden, kann man zunächst prüfen, welche Datensätze von einer Löschbedingung betroffen wären.

Beispielsweise für Sessions, deren time-Wert älter als zehn Tage ist:

SELECT *
FROM `abc_session`
WHERE `time` < UNIX_TIMESTAMP(NOW() - INTERVAL 10 DAY)
LIMIT 10;

Noch übersichtlicher ist zunächst die reine Anzahl:

SELECT COUNT(*)
FROM `abc_session`
WHERE `time` < UNIX_TIMESTAMP(NOW() - INTERVAL 10 DAY);

Damit lässt sich kontrollieren, wie viele Datensätze die Bedingung überhaupt erfasst.

Wichtig: Der Zeitraum von zehn Tagen ist hier ein Beispiel aus der konkreten Bereinigung und keine allgemeingültige Joomla-Empfehlung. Welche Sessions gelöscht werden können, sollte zur Session-Konfiguration der jeweiligen Installation passen.

Alte Session-Einträge löschen

Ist geklärt, dass die entsprechenden Datensätze entfernt werden sollen, lautet die Abfrage beispielsweise:

DELETE FROM `abc_session`
WHERE `time` < UNIX_TIMESTAMP(NOW() - INTERVAL 10 DAY);

Bei sehr vielen Datensätzen kann eine solche Abfrage über phpMyAdmin allerdings problematisch werden. Bei der untersuchten Installation kam es bei einer größeren Operation zu einem HTTP-500-Fehler bzw. einem Verbindungsabbruch.

In einem solchen Fall kann es sinnvoll sein, nicht Hunderttausende Datensätze in einer einzigen Operation zu bearbeiten, sondern die Löschung in kleineren Portionen durchzuführen:

DELETE FROM `abc_session`
WHERE `time` < UNIX_TIMESTAMP(NOW() - INTERVAL 10 DAY)
LIMIT 1000;

Der Befehl kann wiederholt ausgeführt werden, bis keine entsprechenden Datensätze mehr vorhanden sind.

In der konkreten Datenbank wurden schließlich rund 300.000 Session-Datensätze entfernt.

Warum wird die Datenbank nach dem Löschen kaum kleiner?

Das war der überraschende Teil: Obwohl rund 300.000 Datensätze gelöscht worden waren, sank die angezeigte Gesamtgröße der Datenbank zunächst nur geringfügig.

Das bedeutet nicht, dass MariaDB die gelöschten Datensätze in einem „Papierkorb“ aufbewahrt.

Bei InnoDB führt ein DELETE jedoch nicht zwangsläufig dazu, dass der zuvor von einer Tabelle belegte Speicherplatz unmittelbar als kleinere Tabellendatei sichtbar wird. Frei gewordener Platz kann zunächst innerhalb der Tabelle wiederverwendbar bleiben.

Deshalb kann nach einer großen Löschaktion eine Neuorganisation der Tabelle sinnvoll sein.

Tabelle mit OPTIMIZE TABLE neu organisieren

Dazu kann man ausführen:

OPTIMIZE TABLE `abc_session`;

Bei der untersuchten InnoDB-Tabelle meldete MariaDB daraufhin:

Table does not support optimize, doing recreate + ...

Diese Meldung ist in diesem Zusammenhang nicht automatisch ein Fehler. MariaDB weist damit darauf hin, dass die Optimierung bei dieser Tabelle über einen Neuaufbau erfolgt.

Gerade bei einer großen Tabelle sollte man berücksichtigen, dass ein solcher Vorgang erheblich aufwendiger sein kann als ein gewöhnliches DELETE.

Größe anschließend erneut kontrollieren

Nach der Bereinigung kann die Tabellengröße erneut abgefragt werden:

SELECT
    table_name,
    ROUND(data_length / 1024 / 1024, 2) AS data_mb,
    ROUND(index_length / 1024 / 1024, 2) AS index_mb,
    ROUND((data_length + index_length) / 1024 / 1024, 2) AS total_mb
FROM information_schema.tables
WHERE table_schema = 'DATENBANKNAME'
ORDER BY (data_length + index_length) DESC;

Das ist auch für die weitere Analyse nützlich: Statt wahllos Joomla-Tabellen zu bereinigen, sieht man sofort, welche Tabellen tatsächlich relevant für die Gesamtgröße sind.

Ein zusätzlicher Joomla-Schalter: „Track Guest Session Metadata“

Bei der Analyse fiel außerdem die Joomla-Einstellung „Track Guest Session Metadata“ auf.

Da die untersuchte Installation gerade durch sehr viele Session-Datensätze auffällig geworden war, ist diese Einstellung ein naheliegender Punkt für die weitere Ursachenanalyse. Aus der hier beschriebenen Untersuchung allein lässt sich allerdings nicht belegen, dass diese Option das starke Wachstum verursacht hat.

Deshalb sollte man sie nicht allein aufgrund der Datenbankgröße deaktivieren, sondern zunächst prüfen, ob und wofür die Installation Gast-Session-Metadaten benötigt.

Was sich aus der Analyse ableiten lässt

Die wichtigste Erkenntnis war weniger ein einzelner SQL-Befehl als die Reihenfolge der Fehlersuche:

1. Zuerst die tatsächlichen Größen aller Tabellen ermitteln.
2. Bei einer auffälligen Session-Tabelle Struktur und Anzahl der Datensätze prüfen.
3. Den Umfang des Feldes data untersuchen.
4. Alte Datensätze zunächst nur per SELECT bzw. COUNT(*) identifizieren.
5. Erst danach gezielt löschen.
6. Bei sehr großen Datenmengen gegebenenfalls in kleineren Blöcken arbeiten.
7. Nicht erwarten, dass ein DELETE bei InnoDB die sichtbare Tabellengröße sofort entsprechend reduziert.
8. Nach größeren Löschaktionen prüfen, ob eine Neuorganisation der Tabelle erforderlich ist.

Vor allem sollte man nicht anfangen, vermeintlich alte Joomla- oder Erweiterungstabellen auf Verdacht zu löschen. Dass eine Tabelle groß, deaktiviert oder historisch gewachsen ist, beweist noch nicht, dass sie für die aktuelle Installation entbehrlich ist.

Die Session-Tabelle ist dagegen ein gutes Beispiel dafür, wie man eine auffällige Datenmenge zunächst nachvollziehbar analysieren kann, bevor man in die Struktur einer produktiven Joomla-Datenbank eingreift.

Nach einem bestätigten Webshell-Befall reicht es nicht, die schädlichen PHP-Dateien zu löschen und die betroffene Joomla-Erweiterung zu aktualisieren.

Wenn fremder PHP-Code mit den Rechten des Webservers ausgeführt werden konnte, muss man davon ausgehen, dass dieser Code auch auf Dateien zugreifen konnte, die für den Webserver lesbar waren.

Bei Joomla gehört dazu insbesondere die configuration.php.

Damit können nach einem solchen Vorfall verschiedene Zugangsdaten als potentiell offengelegt gelten.

Dieser Beitrag beschreibt, welche Zugangsdaten ich nach einem tatsächlichen Joomla-Webshell-Befall geändert habe – und in welcher Reihenfolge.

Ausgangslage

In meinem Fall waren über eine verwundbare Joomla-Erweiterung PHP-Webshells in den Webspace gelangt.

Damit war bestätigt:

Fremder PHP-Code konnte mit den Rechten des Webspace-Benutzers ausgeführt werden.

Das bedeutet noch nicht automatisch, dass der Server als root kompromittiert wurde.

Aber alles, was der Webspace-Benutzer lesen konnte, musste als potentiell bekannt betrachtet werden.

Dazu gehörte insbesondere:

configuration.php

In dieser Datei stehen unter anderem die Joomla-Datenbankverbindung und weitere Konfigurationswerte.

Erst bereinigen, dann Passwörter ändern

Bevor Zugangsdaten rotiert werden, sollte der offensichtliche Angriffsweg geschlossen sein.

Sonst besteht die Gefahr, dass ein weiterhin vorhandener Webshell die neuen Zugangsdaten einfach erneut ausliest.

Die Reihenfolge war deshalb grundsätzlich:

1. verwundbare Erweiterung aktualisieren bzw. Angriffsweg blockieren,
2. bekannte Webshells und Backdoors sichern und aus dem Webroot entfernen,
3. nach weiteren verdächtigen Dateien und Persistenz suchen,
4. erst danach Zugangsdaten rotieren.

Das bedeutet nicht, dass damit garantiert jede mögliche Hintertür ausgeschlossen ist. Aber neue Zugangsdaten in ein offensichtlich noch kompromittiertes System einzutragen wäre wenig sinnvoll.

1. Joomla-Administratorpasswörter ändern

Zunächst wurden die Passwörter aller aktiven Joomla-Administratoraccounts geändert.

Dabei sollte man nicht nur den Hauptadministrator berücksichtigen.

Im Joomla-Backend lohnt sich die Prüfung:

Benutzer → Verwalten

und dort insbesondere:

• Super Users
• Administratoren
• ältere oder kaum noch verwendete Accounts

Nicht mehr benötigte privilegierte Konten sollten deaktiviert oder entfernt werden.

Wichtig ist außerdem:

Das Passwort sollte neu sein und nicht lediglich eine Variante des bisherigen Passworts.

Wenn Zugangsdaten möglicherweise abgeflossen sind, sollte das alte Passwort auch bei anderen Diensten nicht mehr verwendet werden.

2. Bestehende Joomla-Sitzungen beenden

Ein neues Passwort beendet nicht zwangsläufig jede bereits bestehende Sitzung.

Ein Angreifer könnte theoretisch noch über eine gültige Session verfügen.

Deshalb habe ich zusätzlich die Joomla-Sitzungstabelle geleert.

Der Tabellenname hängt vom Präfix der jeweiligen Joomla-Installation ab und kann beispielsweise so aussehen:

abc_session

Vorher sollte man natürlich prüfen, welche Tabelle tatsächlich zur Installation gehört.

Das Leeren der Session-Tabelle meldet alle aktuell angemeldeten Benutzer ab.

Danach müssen sich auch legitime Administratoren erneut anmelden.

Je nach Joomla-Version und verwendeten Funktionen können außerdem persistente Login-Schlüssel existieren. Auch diese sollten nach einem relevanten Sicherheitsvorfall geprüft bzw. invalidiert werden.

3. Datenbankpasswort rotieren

Dieser Schritt ist besonders wichtig, weil Joomla seine Datenbankzugangsdaten normalerweise in:

configuration.php

speichert.

Wer diese Datei über eine Webshell lesen konnte, konnte damit unter Umständen auch Benutzername und Passwort der Joomla-Datenbank erfahren.

Das Datenbankpasswort sollte deshalb geändert werden.

Dabei gibt es allerdings eine kleine Falle:

Datenbankserver und Joomla müssen anschließend dasselbe neue Passwort kennen.

Ändert man nur das Passwort des MySQL-/MariaDB-Benutzers, kann Joomla keine Datenbankverbindung mehr herstellen.

Ändert man nur configuration.php, gilt dasselbe.

Sinnvolle Reihenfolge beim DB-Passwort

Vorher unbedingt ein Backup der Joomla-Konfiguration anlegen.

Zum Beispiel:

cp -a configuration.php /root/configuration.php-before-db-password-change

Dabei ist zu beachten:

Diese Sicherung enthält anschließend das alte Datenbankpasswort im Klartext.

Sie sollte deshalb:

• außerhalb des Webroots liegen,
• nur für root lesbar sein,
• und nach erfolgreichem Abschluss später sicher gelöscht werden.

Dann:

1. neues Datenbankpasswort erzeugen,
2. Passwort des Datenbankbenutzers ändern,
3. Joomla-configuration.php unmittelbar auf dasselbe Passwort setzen,
4. Datenbankverbindung testen,
5. Webseite testen,
6. Joomla-Backend testen.

Während dieses kurzen Übergangs kann die Webseite vorübergehend einen HTTP-500-Fehler liefern, wenn Datenbank und Joomla-Konfiguration noch nicht synchron sind.

Das allein ist in diesem Moment noch kein Hinweis auf einen neuen Defekt.

Datenbankverbindung direkt testen

Nach der Änderung sollte nicht nur die Webseite getestet werden.

Sinnvoll ist auch ein direkter Verbindungstest mit PHP oder dem MySQL-/MariaDB-Client.

Bei PHP kann beispielsweise ein sehr kleiner Test verwendet werden, ohne das Passwort in der Shell-History zu hinterlassen.

Wichtig ist vor allem:

Verbindung erfolgreich

und anschließend ein normaler Aufruf der Joomla-Seite.

Bei meinem System wurden danach sowohl Startseite als auch Administratorbereich erneut kontrolliert.

Beide mussten wieder HTTP 200 liefern.

4. Passwort des Webspace-/Hosting-Benutzers ändern

Wenn ein Angreifer Code mit den Rechten des Webspace-Benutzers ausführen konnte, ist auch dessen Zugang relevant.

Bei Plesk gibt es dafür typischerweise einen Systembenutzer für die jeweilige Subscription bzw. Domain.

Dieser Benutzer kann je nach Konfiguration beispielsweise für:

• SFTP,
• SSH,
• Dateizugriff,
• Deployment

verwendet werden.

Auch dessen Passwort wurde deshalb geändert.

Selbst wenn keine erfolgreiche SSH-Anmeldung dieses Benutzers nachgewiesen wurde, ist die Rotation sinnvoll, wenn dessen Zugangsdaten irgendwo für den kompromittierten Prozess erreichbar gewesen sein könnten.

5. Private SSH-Schlüssel prüfen

Ein Punkt, den man leicht übersieht:

Im Home-Verzeichnis des Webspace-Benutzers können private SSH-Schlüssel liegen.

Beispielsweise:

~/.ssh/id_rsa

In meinem Fall existierte dort tatsächlich ein privater RSA-Schlüssel ohne Passphrase.

Da der Webshell mit den Rechten dieses Benutzers lief, musste angenommen werden, dass der Schlüssel ausgelesen worden sein könnte.

Der Schlüssel wurde deshalb nicht weiter verwendet.

Bei einem kompromittierten privaten SSH-Schlüssel gilt:

Nicht nur die Datei löschen oder verschieben, sondern auch prüfen, wo der zugehörige öffentliche Schlüssel als authorized_key hinterlegt wurde.

Dort sollte der alte Schlüssel entfernt und gegebenenfalls durch einen neuen ersetzt werden.

6. Muss das Root-Passwort ebenfalls geändert werden?

Nicht zwangsläufig aufgrund der Webshell allein.

Hier ist die Unterscheidung wichtig.

Eine PHP-Webshell beweist zunächst die Kompromittierung des PHP-/Webspace-Kontexts.

Sie beweist nicht automatisch:

root wurde kompromittiert

Das Root-Passwort sollte natürlich geändert werden, wenn es Hinweise gibt auf:

• erfolgreiche unbekannte Root-Logins,
• manipulierte authorized_keys,
• verdächtige Systemdienste,
• Root-Persistenz,
• kompromittierte Administrationszugänge,
• oder eine mögliche Privilege Escalation.

In meinem Fall wurde das Root-Passwort im Zuge der Sicherheitsarbeiten ebenfalls erneuert.

Für die Bewertung des Vorfalls blieb die Formulierung trotzdem:

Webspace-Kompromittierung bestätigt, Root-Kompromittierung nicht nachgewiesen.

Diese Unterscheidung hilft, Beobachtungen und Vermutungen nicht miteinander zu vermischen.

7. Plesk- und Provider-Zugang nicht vergessen

Je nach Hostingumgebung können außerdem weitere Zugangsdaten relevant sein:

Plesk
Hosting-Provider
DNS-Provider
Domain-Registrar
Backup-System
Deployment-Dienste
Git-Zugänge

Ob sie tatsächlich geändert werden müssen, hängt davon ab, ob die entsprechenden Zugangsdaten für das kompromittierte System erreichbar waren.

Ein im Browser gespeichertes Provider-Passwort ist beispielsweise durch eine PHP-Webshell auf dem Server nicht automatisch kompromittiert.

Ein API-Key in einer für den Webserver lesbaren Konfigurationsdatei dagegen schon.

Die bessere Frage lautet also:

Konnte der kompromittierte Benutzer dieses Geheimnis lesen?

8. Auch Mail-Zugangsdaten und API-Keys berücksichtigen

Viele Joomla-Installationen enthalten mehr Geheimnisse als nur die Datenbankverbindung.

Mögliche Beispiele:

SMTP-Passwörter
API-Keys
Cloud-Zugangsdaten
Backup-Credentials
OAuth-Secrets
externe Datenbankzugänge
FTP-/SFTP-Zugangsdaten

Sie können in:

configuration.php
.php-Dateien
.env-Dateien
Backup-Dateien
Erweiterungskonfigurationen

liegen.

Nach einer Webshell-Kompromittierung lohnt sich deshalb die Suche nach weiteren Secrets im Webroot.

Nicht jedes gefundene Passwort muss automatisch geändert werden.

Aber alles, was der kompromittierte Benutzer lesen konnte und noch gültig ist, sollte bewertet werden.

9. Vorsicht mit alten Backups

Während einer Reparatur entstehen schnell Dateien wie:

configuration.php.bak
configuration.php.old
configuration.php-before-change

Diese Backups enthalten häufig dieselben Passwörter wie das Original.

Noch problematischer wird es, wenn solche Dateien versehentlich im öffentlichen Webroot liegen.

Deshalb:

• Konfigurationsbackups möglichst unter /root oder einem anderen nicht öffentlichen Ort ablegen,
• restriktive Dateirechte setzen,
• nach erfolgreicher Reparatur nicht benötigte Kopien löschen.

Ein Passwortwechsel hilft wenig, wenn anschließend zehn alte Konfigurationsbackups mit dem vorherigen Passwort herumliegen.

10. Nach jeder Änderung testen

Bei mehreren gleichzeitigen Passwortänderungen kann es sonst schwierig werden herauszufinden, welcher Schritt eine Anwendung beschädigt hat.

Deshalb habe ich die Änderungen nacheinander durchgeführt und jeweils getestet.

Typische Tests:

curl -I https://example.org/

Erwartet:

HTTP 200

Zusätzlich:

Frontend aufrufen
Joomla-Backend aufrufen
Administrator-Login testen
Datenbankzugriff prüfen

So lässt sich ein Fehler unmittelbar dem letzten Änderungsschritt zuordnen.

11. Neue Zugangsdaten nicht in der Shell-History hinterlassen

Gerade bei der Arbeit als root sollte man vermeiden, Passwörter direkt in Befehle einzutragen wie:

mysql -u user -pSUPERGEHEIMESPASSWORT

Denn je nach Shell und Konfiguration kann dieser Befehl in der History landen.

Besser ist:

mysql -u user -p

Danach fragt der Client das Passwort interaktiv ab.

Dasselbe Prinzip gilt für andere Programme, sofern sie eine sichere Passwortabfrage anbieten.

12. Reihenfolge aus der Praxis

Nach dem konkreten Vorfall hat sich für mich folgende Reihenfolge als sinnvoll erwiesen:

1. Sicherheitslücke schließen.
2. bekannte Webshells und Backdoors entfernen bzw. quarantänisieren.
3. nach weiterer Persistenz suchen.
4. Joomla-Administratorpasswörter ändern.
5. Joomla-Sessions invalidieren.
6. Datenbankpasswort ändern und configuration.php synchron aktualisieren.
7. Datenbank und Webseite testen.
8. Passwort des Webspace-/Hosting-Benutzers ändern.
9. vorhandene private SSH-Schlüssel bewerten und gegebenenfalls ersetzen.
10. weitere für den Webserver lesbare Secrets prüfen.
11. Plesk-, Provider- und DNS-Zugänge nach Risikolage bewerten.
12. alte Backups mit inzwischen ungültigen oder sensiblen Zugangsdaten aufräumen.
13. anschließend erneut Logs, Prozesse und Dateisystem kontrollieren.

Was ein Passwortwechsel nicht leistet

Eine Credential-Rotation ist wichtig.

Sie beseitigt aber keine Malware.

Wenn weiterhin eine Webshell aktiv ist, können neue Passwörter möglicherweise sofort wieder abgegriffen werden.

Umgekehrt bedeutet eine erfolgreiche Bereinigung des Webroots nicht, dass alte Zugangsdaten weiterhin bedenkenlos verwendet werden sollten.

Beides gehört zusammen:

Bereinigung + Zugangsdatenrotation

Kurzfassung

Nach einem bestätigten Joomla-Webshell-Befall würde ich mindestens folgende Dinge prüfen bzw. erneuern:

Joomla-Administratorpasswörter
Joomla-Sitzungen
Datenbankpasswort
Webspace-/Hosting-Benutzer
private SSH-Schlüssel
SMTP-/API-/sonstige Secrets

Weitere Administrationszugänge wie:

root
Plesk
Hosting-Provider
DNS
Domain-Registrar

sollten abhängig davon bewertet werden, ob es einen realistischen Zugriffspfad oder konkrete Hinweise auf eine Kompromittierung gibt.

Die wichtigste Grundregel lautet:

Alles, was ein kompromittierter Webspace-Benutzer lesen konnte, sollte als potentiell offengelegt betrachtet werden.

Und genauso wichtig:

Eine PHP-Webshell beweist nicht automatisch eine Root-Kompromittierung.

Diese beiden Aussagen helfen, nach einem Vorfall weder zu wenig noch unnötig viel aus den vorhandenen Spuren abzuleiten.

Nach einem Joomla-Sicherheitsvorfall tauchten in der Google Search Console plötzlich zahlreiche URLs unter Subdomains auf, die ich selbst nie eingerichtet hatte.

Beispiele sahen sinngemäß so aus:

m.example.org/...
admin-v2.example.org/...
monitor.example.org/...
wildcard.example.org/...

Das wirkte zunächst so, als hätte jemand diese Subdomains auf dem Server angelegt.

Die eigentliche Ursache war aber eine Kombination aus zwei Dingen:

1. Die Joomla-Seite war zuvor kompromittiert worden und Google hatte dabei ungewöhnliche bzw. manipulierte URLs entdeckt.
2. Für die Domain existierte ein Wildcard-DNS-Eintrag, durch den praktisch jede beliebige Subdomain auf denselben Webserver zeigte.

Der Wildcard-DNS-Eintrag war also nicht die Ursache des Hacks. Er wirkte aber wie ein Verstärker für die unerwünschte Indexierung.

Was ist ein Wildcard-DNS-Eintrag?

Ein Eintrag wie

*.example.org   A   203.0.113.10

bedeutet:

Jede nicht ausdrücklich definierte Subdomain von example.org soll auf diese IP-Adresse zeigen.

Damit funktionieren nicht nur bewusst angelegte Hosts wie:

www.example.org
mail.example.org

sondern grundsätzlich auch:

test.example.org
abc.example.org
m.example.org
admin-v2.example.org
monitor.example.org
irgendwas.example.org

sofern dafür kein spezifischerer DNS-Eintrag existiert.

Ein Test ist einfach:

dig zufallsname-12345.example.org A +short

Wenn dort dieselbe Server-IP zurückkommt, obwohl diese Subdomain nie eingerichtet wurde, ist sehr wahrscheinlich ein Wildcard-DNS-Eintrag aktiv.

DNS allein reicht noch nicht

Ein wichtiger Punkt:

Der Wildcard-DNS-Eintrag allein sorgt noch nicht dafür, dass eine Webseite unter jeder Subdomain erscheint.

DNS beantwortet zunächst nur die Frage:

Auf welche IP-Adresse soll dieser Hostname zeigen?

Danach entscheidet der Webserver, was mit dem HTTP-Request passiert.

Wenn Apache, nginx oder die Hosting-Konfiguration unbekannte Hostnamen einfach an dieselbe Joomla-Installation weiterleitet, kann die Webseite tatsächlich auch unter beliebigen Subdomains erreichbar sein.

Dann wird aus:

https://www.example.org/artikel

möglicherweise ebenfalls:

https://m.example.org/artikel
https://monitor.example.org/artikel
https://abc.example.org/artikel

Wenn diese Varianten öffentlich erreichbar sind, können auch Suchmaschinen sie entdecken.

Der Zusammenhang mit einem Joomla-Hack

In meinem Fall war zuvor eine Joomla-Erweiterung kompromittiert worden.

Dabei waren unter anderem ungewöhnliche URLs entstanden, die von Google gecrawlt wurden.

Eine davon verwies beispielsweise auf eine hochgeladene PHP-Datei innerhalb einer Joomla-Komponente.

Google kann solche URLs unter anderem über externe Links, Crawling, Sitemaps, interne Verweise oder bereits bekannte URL-Muster entdecken.

Wenn gleichzeitig jede beliebige Subdomain auf dieselbe Joomla-Seite zeigt, vervielfacht sich die Zahl potentiell erreichbarer URL-Varianten.

Aus einer URL kann dann theoretisch eine ganze Familie werden:

example.org/pfad
m.example.org/pfad
admin-v2.example.org/pfad
monitor.example.org/pfad
foo.example.org/pfad
bar.example.org/pfad

Das bedeutet nicht zwangsläufig, dass ein Angreifer jede dieser Subdomains bewusst eingerichtet hat.

Sie können schlicht deshalb funktionieren, weil:

*.example.org

auf denselben Server zeigt.

So habe ich den Wildcard-Eintrag gefunden

Zunächst wurde die öffentliche DNS-Konfiguration überprüft.

Ein Test mit einer frei erfundenen Subdomain ist dafür besonders hilfreich:

dig diesegibtesgarantiertnicht.example.org A

Wenn die Antwort beispielsweise lautet:

diesegibtesgarantiertnicht.example.org. 86400 IN A 203.0.113.10

ist klar:

Auch nicht eingerichtete Subdomains werden aufgelöst.

Anschließend sollte man die DNS-Zone beim tatsächlichen DNS-Provider prüfen.

Gesucht wird nach einem Eintrag wie:

*

bzw.

*.example.org

mit einem A- oder AAAA-Record.

Zusätzlich prüfen, ob der Webserver die Subdomain annimmt

Nach der DNS-Prüfung sollte getestet werden, was der Webserver mit einem erfundenen Hostnamen macht.

Zum Beispiel:

curl -I https://zufall-12345.example.org/

Wenn die Seite dort normal mit:

HTTP/2 200

antwortet, wird der unbekannte Hostname tatsächlich von der Webseite bedient.

Für einen gezielten Test gegen eine bestimmte Server-IP kann curl auch ohne Änderung des öffentlichen DNS verwendet werden:

curl --resolve zufall-12345.example.org:443:203.0.113.10 \
  -I https://zufall-12345.example.org/

Damit wird für diesen einzelnen Test so getan, als würde der Name auf die angegebene IP zeigen.

Wildcard-DNS entfernen

Wenn beliebige Subdomains nicht benötigt werden, kann der Wildcard-Eintrag entfernt werden.

Danach sollte ein Test wie:

dig zufall-12345.example.org A +short

keine Server-IP mehr zurückgeben.

Wichtig ist dabei die DNS-TTL.

Bei einem Eintrag mit beispielsweise:

86400

beträgt die maximale Cache-Zeit:

86400 Sekunden = 24 Stunden

Ein bereits aufgelöster Wildcard-Eintrag kann deshalb noch eine Zeit lang in DNS-Caches vorhanden sein.

Das bedeutet nicht, dass die Änderung nicht funktioniert hat.

DNS entfernen reicht langfristig nicht immer aus

Zusätzlich zur DNS-Bereinigung ist es sinnvoll, den Webserver so zu konfigurieren, dass unbekannte Hostnamen nicht einfach dieselbe Joomla-Seite ausliefern.

Ein Server sollte idealerweise nur die ausdrücklich vorgesehenen Hosts akzeptieren, zum Beispiel:

example.org
www.example.org

Unbekannte Hosts können stattdessen:

• abgewiesen werden,
• einen Fehlerstatus liefern,
• oder kontrolliert auf die kanonische Domain umgeleitet werden.

Welche Variante sinnvoll ist, hängt von der jeweiligen Server- und Hosting-Konfiguration ab.

Der Vorteil:

Selbst wenn später versehentlich wieder ein DNS-Eintrag auf den Server zeigt, liefert der Webserver nicht automatisch die eigentliche Joomla-Seite aus.

Canonical-Tags helfen, lösen das Problem aber nicht allein

Joomla bzw. SEO-Erweiterungen können sogenannte Canonical-URLs ausgeben.

Beispielsweise:

<link rel="canonical"
      href="https://www.example.org/artikel">

Damit wird Suchmaschinen signalisiert:

Diese URL ist die bevorzugte Version des Inhalts.

Das ist hilfreich, ersetzt aber keine saubere DNS- und Webserver-Konfiguration.

Wenn hunderte oder tausende alternative Hosts öffentlich dieselben Inhalte ausliefern, sollte die Ursache behoben werden, statt sich nur auf Canonical-Tags zu verlassen.

Warum Google die alten URLs trotzdem noch zeigt

Nachdem der Wildcard-DNS-Eintrag entfernt wurde, verschwinden die betreffenden URLs nicht sofort aus der Google Search Console.

Google kennt diese Adressen weiterhin aus seinem bisherigen Crawl.

Erst wenn Google sie erneut besucht und feststellt, dass sie nicht mehr erreichbar sind oder korrekt umgeleitet werden, kann sich der Index entsprechend ändern.

Das kann deutlich länger dauern als die DNS-Umstellung selbst.

Deshalb sollte man unterscheiden:

DNS

Die Änderung kann – abhängig von der TTL – innerhalb von Stunden wirksam werden.

Google-Index

Bereits bekannte URLs können noch Tage, Wochen oder länger in Berichten auftauchen.

Eine alte URL in der Search Console ist deshalb nicht automatisch ein Hinweis darauf, dass sie aktuell noch funktioniert.

Stichproben nach der Änderung

Nach Ablauf der DNS-TTL lohnt sich ein erneuter Test:

dig zufall-67890.example.org A +short

Erwartetes Ergebnis:

keine Ausgabe

Danach können einige der zuvor von Google gefundenen Hosts geprüft werden.

Beispielsweise:

dig m.example.org A +short
dig admin-v2.example.org A +short
dig monitor.example.org A +short

Wenn diese Namen nie benötigt wurden, sollten sie nach der Bereinigung nicht mehr auf den Webserver zeigen.

Wildcard-DNS ist nicht grundsätzlich schlecht

Ein Wildcard-Eintrag ist kein Sicherheitsproblem per se.

Es gibt legitime Anwendungen, beispielsweise:

kunde1.example.org
kunde2.example.org
kunde3.example.org

wenn eine Anwendung dynamisch beliebige Subdomains verwendet.

Problematisch wird ein Wildcard-Eintrag vor allem dann, wenn:

• er gar nicht benötigt wird,
• niemand mehr weiß, warum er existiert,
• der Webserver jeden beliebigen Host akzeptiert,
• oder ein kompromittiertes System dadurch unter vielen Hostnamen erreichbar wird.

In einer normalen Joomla-Webseite mit wenigen fest definierten Domains gibt es häufig keinen Grund, jede denkbare Subdomain auf dieselbe Installation zeigen zu lassen.

Was der Wildcard-Eintrag nicht beweist

Bei der Untersuchung eines Hacks ist auch hier Vorsicht bei Schlussfolgerungen wichtig.

Ein Eintrag wie:

*.example.org

beweist nicht:

Ein Angreifer hat hunderte Subdomains angelegt.

Tatsächlich wurde möglicherweise keine einzige davon individuell eingerichtet.

Ebenso beweist eine bei Google auftauchende Adresse wie:

admin-v2.example.org

nicht automatisch, dass dort tatsächlich ein Administrationssystem existierte.

Der Name kann vollkommen beliebig sein.

Der entscheidende Test ist deshalb immer:

Warum löst dieser Hostname überhaupt auf und was liefert der Server bei einem Request dorthin aus?

Kurzfassung

Symptom

Google kennt plötzlich viele unbekannte Subdomains wie:

m.example.org
admin-v2.example.org
monitor.example.org

Mögliche Ursache

In der DNS-Zone existiert:

*.example.org

und zeigt auf denselben Webserver wie die eigentliche Webseite.

Zusätzliche Voraussetzung

Der Webserver akzeptiert die unbekannten Hostnamen und liefert dafür ebenfalls die Joomla-Seite aus.

Folge

Beliebig viele Hostnamen können auf dieselben oder auf kompromittierte Joomla-URLs zeigen und von Suchmaschinen entdeckt werden.

Lösung

Wenn Wildcard-Subdomains nicht benötigt werden:

1. Wildcard-DNS-Eintrag entfernen.
2. DNS-TTL abwarten.
3. Zufällige Subdomains mit dig testen.
4. Webserver so konfigurieren, dass nur vorgesehene Hostnamen akzeptiert werden.
5. Canonical-URLs kontrollieren.
6. Google die alten URLs anschließend neu crawlen lassen.

Fazit

Der Wildcard-DNS-Eintrag war in meinem Fall nicht die Ursache der Joomla-Kompromittierung.

Er erklärte aber, warum völlig frei erfundene Subdomains dieselbe Joomla-Webseite auslieferten und warum Google ungewöhnlich viele Hostvarianten kennen konnte.

Die wichtigste Erkenntnis war deshalb:

Bei merkwürdigen Subdomains nach einem Website-Hack nicht automatisch davon ausgehen, dass diese einzeln angelegt wurden. Zuerst DNS-Wildcards und die Host-Konfiguration des Webservers prüfen.

Gerade die Kombination aus kompromittierten URLs, Wildcard-DNS und einem Webserver, der unbekannte Hostnamen akzeptiert, kann einen einzelnen Vorfall im Suchmaschinenindex deutlich größer erscheinen lassen, als er technisch tatsächlich ist.

Schlaglichter aus der Eingangsdiskussion:

• Problem kostenpflichtiger KI-Anbieter: Datensouveränität; was passiert mit den Daten, spätestens nach Ende der Lizenzierung
• Alternative: telli, seit 01.10. im Rahmen des Schulportals verfügbar (weitere Funktionen in Entwicklung)
• Anwendungsfelder für KI in der Grundschule (und nicht nur da): Elternkommunikation; Materialdifferenzierung; (geplant in „telli“) Spracheingabe und -ausgabe
• Aktuelle Frage im HMKB: Gehen KI-spezifische Themen im aktuellen Kompetenzrahmen Medienbildung auf oder benötigen sie einen eigenen Kompetenzrahmen?

Mögliche Kompetenzfelder im Kontext mit KI:

• KI-Grundwissen und souveräne Haltung zu KI
• Ethischer Umgang mit KI
• KI-generierte Inhalte überprüfen und ausweisen
• Anwendungen kennen und gezielt nutzen

Fragen für einen Pädagogischen Tag zu KI

Schulrecht und -organisation

• Welche Rolle spielt die Schulleitung in der Planung und Durchführung des Pädagogischen Tages und im weiteren Prozess?
• Wie sieht der rechtliche Rahmen für den Umgang mit KI aus? (s. KMK-Strategie, Handreichung des HMKB)
• Wie kann eine Nutzungsordnung für KI an der Schule aussehen?
• Wie kann Engagement bei freiwilligen Veranstaltungen wertgeschätzt werden, auch durch Entlastung an anderer Stelle?

Qualifikation des Kollegiums

• Welche Expertise ist im Kollegium vorhanden und wie kann sie beim Pädagogischen Tag verwendet werden?
• Wie kann grundlegendes Anwendungswissen auch bei Skeptiker:innen geschaffen werden?
• Wie werden unterschiedliche Ausgangsniveaus bei den Lehrkräften berücksichtigt? (–> Binnendifferenzierung im Kollegium)
• Wie kann man Erprobungsräume zur direkten Anwendung ermöglichen? (Bsp.: direkte Anwendung in telli)

Entwicklung von Schule, Unterricht und Prüfung

• Wie sieht eine angemessene Prüfungskultur in Zeiten von KI (und vor dem Hintergrund der Prüfungsordnungen) aus?
• Wie umgehen mit der Unsicherheit, ob Lernendenprodukte KI-generiert sind (da Prüf-Software nicht zuverlässig/justiziabel ist)?
• Welche Freiräume bestehen und wie können sie genutzt werden? (Bsp. Präsentationsprüfung: Gewichtung der Benotung durch Fachschaften festlegen lassen)
• Wie sichert man Nachhaltigkeit im Rahmen des Pädagogischen Tages? (Bsp.: Thema erneut anhand von regionalen Angeboten noch einmal aufgreifen, etwa über die Medienfachberatung; KI-Gruppe an der Schule einrichten mit regelmäßigen Treffen; Edumap mit Anwendungsbeispielen)
• Gibt es Schulen im Umfeld, die man zwecks Austausch zum Pädagogischen Tag (oder zu einem Teil davon) einladen kann?

Relevante Links aus der Sitzung

KI-Fortbildungen (LA)

Pädagogische Tage und Kollegiale Lernwochen zu Medienbildung (LA)

Flicken Sticken

Problem

My dachshunds chewed a hole in my jacket pocket. Not just an ordinary jacket, but a kind of Janker, a type of Bavarian traditional jacket, mostly knitted from wool. Beautifully crafted, with contrasting felt patches and a few embroidered traditional motifs. And I'd only worn it three times.

Of course, the dachshunds chewed a decent-sized hole through the wool from the outside, which can't just be sewn up.

So the most obvious solution was to patch it up. With felt and, of course, embroidery. Visiting several specialty stores did not yield satisfactory results: hundreds of patches, but nothing suitable, many of them too banal. Edelweiss, roaring deer, or mountain panoramas.

Than, the

Idea

Picasso created a whole series of pictures drawn with a single line. One of them features a dachshund as its motif. What would it look like if you drew a dachshund yourself and used a piece of felt with the pattern generated in TurtleStitch and edited in Inkscape? It would be a “nice” reminder of the evildoers, look good, and of course combine different tools and techniques.

Let's get started. What do we need?

Hardware

• Embroidery machine: In this case, a Bernina B 590, but any other embroidery machine will do. The Bernina has a bit of a learning curve, as the display controls are far from intuitive.
• Felt: There is a wide selection available, but it should, of course, match the color of the jacket.
• Darning needles, embroidery needles, and pins
• Embroidery thread and wool

Software

• TurtleStitch: A simple yet ingenious software program that uses a block-based programming environment to generate files for controlling embroidery machines. Based on Snap!, it allows you to create very complex shapes in your browser and, with the appropriate code, implement modules for “tracing” templates, for example.
• Inkscape: ... is an open source vector graphics program. To control embroidery machines, you also need the “Ink/Stitch” extension, which can be installed with little effort.
• and for creating some tools: TinkerCAD (no direct link, because it's not FLOSS), PrusaSlicer and OctoPrint

Realisation

• Drawing a template with a felt-tip pen: First, we need a template that we can scan and then trace on the screen. In principle, you could of course use Picasso's original, but with a little practice, you can do it yourself quite neatly. It's just a single line...
• Create the pattern using the “Line Drawing” module in TurtleStitch. This module allows you to use a hand-drawn sketch as the background for an embroidery pattern and trace this template with the mouse. If you are looking for a detailed description, you will find it in the wonderful Elaine Wolfe's blog post Coding in TurtleStitch – Drawing Like Picasso. There, she explains in simple steps how to trace a scanned image, make initial adjustments, and then export it.
• However, this project is also about exploring other tools. Therefore, the basic function of transferring the line into a running stitch is sufficient. To keep various editing options open, we export the result in both .svg and .dst or .exp format. This depends on the embroidery machine used.
• The “Ink/stitch” extension for Inkscape offers a simple but powerful way to edit embroidery files. With the tools provided by Inkscape, a vector drawing program, it is possible to alter or expand the motif transferred from TurtleStitch without additional programming by rotating/scaling/moving it or adding text. The YouTube channel “Project Anonymous” (no, not what you think, just father and daughter) provides an excellent introduction, and it has an extensive playlist on Ink/Stitch. After a few attempts, it was clear: there had to be three dachshunds, and they could be different colors. Green tones were preferred, of course, as these already appear in the other appliqués on the jacket.
• Cut out and sew on with rough stitches. Sounds easy at first, but it's not. How big should the patch be? What shape should it be? Will it fit the hole? These and other questions need to be answered. An easy way to find a good size for the patch and check the fit and position is, of course, to use a template. Fortunately, a well-equipped household has a 3D printer, so TinkerCAD can be used to quickly draw a suitable shape, which is then sliced with Prusa Slicer and printed on the 3D printer with OctoPrint. With the printed template, you can now quickly check whether the hole is covered, whether the motif fits reasonably well on the patch, and then also create a mark for cutting the patch. If everything fits, it's time for the final step: sewing it onto the jacket. Since the hole is above the pocket and I didn't want to cut it out and then sew it back in again, I had to do this by hand. Secure the patch with pins and then slowly sew it on all around with a large needle and matching wool.

Finished!

This is the result

And here is the restored jacket, which is now socially acceptable again 😄

Insights

1. Never forget to take the dog treats out of your jacket pocket.
2. Learning is always a journey.

Friendica ist nicht Facebook

Wie alles begann

Willi bei Mastodon hat vor einigen Tagen geschrieben:

Alternativen zu #Facebook gibt es wohl immer noch nicht so wirklich, oder? Hab mir die üblichen Verdächtigen mal grob angeschaut und nichts überzeugt mich wirklich... :–/

Ich habe ihn gefragt, was er sich denn wünscht bzw. welche Funktionalität er vermisst. Er hat mit einer ganzen Liste von Anforderungen geantwortet, die ich jetzt mal versuche abzuarbeiten.
Bei der Beantwortung habe ich mich auf Friendica beschränkt, sicher finden sich auch bei anderen Plattformen Ansätze, diese Anforderungen umzusetzen. Immer dann, wenn Friendica etwas auch kann, bekommt es einen Punkt. Wenn ich unsicher bin, eher keinen, aber ich versuche zu erklären, ob was geht und wenn nicht, warum. Da ich seit mehreren Jahren Facebook nicht mehr nutze und meinen Account dort gelöscht habe, musste ich mir einen neuen Account anlegen – Opfer muss jeder von uns bringen – und damit sind wir schon beim ersten Punkt.

Fangen wir an

• Klarnamen – Da scheiden sich die Geister. Wer auf Klarnamen besteht, muss auch darauf bestehen, dass bei der Erstellung des Accounts eine Überprüfung der Identität mit Hilfe eines amtlichen Ausweisdokuments stattfindet. Sicher möglich, schließt aber, zumindest ohne zusätzlichen Aufwand, alle Menschen, die nicht volljährig sind, erst einmal aus. Kann man gut finden, die Meinungen gehen da auseinander. Und alle, die kein Ausweisdokument zur Teilnahme an gesellschaftlichem Austausch vorlegen wollen, auch. Ist aber jetzt nicht unbedingt der entscheidende Punkt, denn was nutzt mir der schönste “Klarname”, wenn er falsch ist. 10 Sekunden dauert es, ein Profil mit dem Namen “Kalle Wirsch” bei Facebook anzulegen. ;–) An dieser Stelle also +1 für Friendica
• Profil mit Infos – Gibt es bei Friendica und ohne alle Optionen eines Profils durchgespielt zu haben, behaupte ich mal, dass es mindestens so umfangreich zu nutzen ist wie drüben bei Facebook. Deshalb auch hier +1 für Friendica
  
• Galerie – Hmm, keine Ahnung, wo bei Facebook eine “Galerie” ist, aber bei Friendica heißt das “Bilder” und zeigt alle Bilder die von einem Profil verwendet wurden. Dazu kommt dann noch die Möglichkeit, die Anzeige von Kanälen nach Bildern, Audio und Video zu begrenzen und in Profilen außer Bildern auch “andere Medien” anzusehen. Da mir noch nicht ganz klar ist, was das Besondere bei Facebook sein soll, hier mal kein Punkt für Friendica
• Timeline – Ja, viele verschiedene, heißen bei Friendica “Kanäle” und bieten eine deutlich differenzierte Einsicht in die Welt. Entweder ganz weit und allumfassend oder nur ganz nah, in meinem direkten Umfeld. Das steuere ich selbst, ich bin der Algorithmus. Man kann das gut bei dem für diesen Beitrag neu angelegten Account (den ich danach wieder lösche) sehen: Facebook schiebt kontinuierlich Inhalte in meine Timeline, da es aber bisher nicht weiß, wie es meinen Blutdruck anheben kann, sind die Inhalte sehr indifferent. Definitiv +1 für Friendica
• Markierungen – Keine Ahnung, was das ist, vermute aber es geht um Lesezeichen. Diese heißen bei Facebook “Gespeichert”. Bei Friendica heißt es tatsächlich “Markierte” und ist eine Lesezeichenliste. ;–) Ein weiteres +1 für Friendica
• Events – Gibt es, heißt Kalender und kann mit unterschiedlichen Sichtbarkeiten dazu genutzt werden, eigene Termine & Veranstaltungen für andere anzuzeigen. Da es sich aber etwas von dem Veranstaltungsankündigungsrummel bei Facebook unterscheidet, denn dafür gibt es im Fediverse einen eigenen Dienst, Mobilizon, hier kein Punkt
• Gruppen – Gibt es auch, also wieder +1
• Einstellungen Sichtbarkeit Beiträge – Gibt es natürlich +1
• PMs – gibt es in Friendica, sind aber nicht verschlüsselt. Liegt an der Konstruktion des Protokolls und daran, dass dieses nicht konzipiert wurde, um gesichert zu kommunizieren. Dafür nutzt man tunlichst einen Messenger der E2E-Verschlüsselung umsetzt und nicht Facebook. :-D wieder +1 für Friendica
  
• Gutes und ansprechendes UI in App bzw. Website – Das ist 1. Geschmackssache und 2. Gewöhnungssache. Beides bedienen die großen Anbieter seit vielen Jahren sehr geschickt. Aber es bedeutet nicht, dass man nicht die Bedienung eines anderen Interfaces erlernen kann. Es ist eine Mischung aus Muskelgedächtnis und Faulheit – beides kann man überwinden

Und definitiv auch ein “nicht seltsamer” Name und einfacher Einstieg für DAUs ohne “welche Instanz muss ich wählen”.

Das war dann die letzte Forderung in der Liste. Dazu gleich mehr, aber vielleicht schauen wir erst mal, was Friendica alles kann, was Facebook nicht kann:

• Austausch mit Menschen auf anderen Social-Media-Plattformen. Bilder, Videos, Kurznachrichten, Diskussionsgruppen, Streaming usw. sind nur ein Teil der Inhalte, die in zentral organisierten Systemen nicht miteinander verbunden werden können. In deföderierten Systemen mit einem einheitlichen Protokoll ist das jedoch überhaupt kein Problem. Besser noch, es ist Teil des Systemdesigns. Stellt euch vor, man könnte von Facebook aus Freunden bei Snapchat folgen. Mit Friendica – und allen anderen Anwendungen im Fediverse kann man das ohne Probleme.
• Formatierte Texte gibt es in Friendica entweder über den Editor oder durch die direkte Eingabe von Markdown-Befehlen. Facebook kann das nach 20 Jahren weiterhin nicht. Das ist natürlich nur eine Kleinigkeit, zeigt aber, wie unterschiedlich sich Systeme entwickeln können.
  

Zwei Punkte haben wir jetzt noch zum Abschluss: “nicht seltsamer Name” und “welche Instanz muss ich wählen”. Beides sind keine Einwände, sondern Vorwände. Wenn ich nicht will, komme ich genau mit solchen Oberflächlichkeiten. Tagtäglich akzeptieren Menschen die unterschiedlichsten Namen, ohne daran zu verzweifeln. Warum dann beim Wechsel zu einer anderen, freien sozialen Plattform. “Instanz wählen” ist ebenfalls vorgeschoben. Menschen sind in der Lage aus dutzenden Autoherstellern mit mehreren tausend Varianten und Modellen das für sie geeignete Fahrzeug zu finden. Auf der anderen Seite zögern sie keine Sekunde, den erstbesten Server auszuwählen bzw. dies nicht zu hinterfragen. Irgendwo dazwischen liegt die Entscheidung für “Welchen Dienst will ich nutzen und welcher Server ist dafür geeignet”, es gibt ausreichend Auswahl nach Sprache, Standort, Hobbys. Es gibt unzählige Seiten, um einen Einstieg zu finden. Sehr ausführlich rund um das Fediverse ist z.B. des Join Fediverse Wiki, einen schnellen Einstieg in Mastodon gibt es z.B. in einem Beitrag des Medienzentrum Frankfurt. Dazu kommen noch die FediTips oder eine Liste von Starter Paketen, die derzeit noch etwas unsortiert sind, aber beim Durchscrollen findet man schon gute Profile für mögliche Follows.

tl;dr

Das mit den Pluspunkten ist natürlich Unfug bzw. gar nicht nötig. Bis auf zwei oder drei der Anforderungen können Friendica und andere Angebote im Fediverse mindestens das, was Facebook kann. Einziger Unterschied: Ich muss bereit sein, eigenverantwortlich und selbstständig zu handeln. Das scheint mir jedoch bei den meisten Menschen die größte Herausforderung zu sein.

Gemeinsam in der Digitalen Welt

Ein großes und spannendes Projekt wie das neue Fach “Digitale Welt” gelingt am besten durch kollegialen Austausch, Vernetzung und das Teilen gelingender Erfahrungen. Um Lehrkräfte und Schulen bei der Einführung und Umsetzung dieses Fachs zu unterstützen, bietet das Medienzentrum Frankfurt zusammen mit den anderen hessischen Medienzentren verschiedene Fortbildungs- und Einführungsveranstaltungen im Rahmen der sogenannten Makertage an. An diesen Tagen sollen Lehrer_innen der Projektschulen aus dem Programm “Digitale Welt” die Möglichkeit bekommen, in die verschiedensten Makertechnologien hineinzuschnuppern und so neue Möglichkeiten zur Umsetzung des Projektes “Digitale Welt” entdecken.

Beispiele gelingender Praxis im Makerspace

Ein wichtiger Bestandteil der “Digitalen Welt” ist die Integration des didaktischen Konzepts der Maker Education. Hierzu gehört die Planung und Umsetzung eigener Projekte im Makerspace. Diese praktischen Erfahrungen fördern das kreative und technische Verständnis der Schüler_innen.

Wie erklären Sie jemandem, der sie fragt, wie ein Makerspace funktioniert, wie ein Makerspace funktioniert?

Makerspaces sind in aller Munde und ein beliebtes Thema auf allen Ebenen des Bildungssystems. Oft ist jedoch unklar, worum es dabei konkret geht und vor allem, wie man so einen Makerspace plant, realisiert und dann im laufenden Schulbetrieb nutzt.

Im Medienzentrum Frankfurt haben wir deshalb genau das gemacht: Einen kleinen Makerspace geplant, realisiert und nutzen ihn jetzt im „Schulbetrieb“. Wir beschulen dort nicht Kinder und Jugendliche, sondern die Lehrer_innen, die an ihrer Schule gerne mal etwas Neues ausprobieren wollen und vielleicht sogar schon erste Anfragen aus dem Kollegium oder der Schulleitung hatten und sich bereits mit ersten Informationen versorgt haben.

Makertage MZ Frankfurt

Um selbst einmal einen solchen Raum zu erleben und die Anwendung von Makerwerkzeugen und Tüfteltechniken in der “Digitalen Welt” zu erkunden, laden wir Sie zu den Makertagen im Medienzentrum Frankfurt ein. An drei aufeinanderfolgenden Tagen, jeweils von 14:00 Uhr bis 17:30 Uhr, haben Sie die Möglichkeit, gemeinsam mit anderen Lehrkräften im makerLAB@medienzentrum zu experimentieren und neue Ideen zu entwickeln.

Durch diese Angebote möchten wir sicherstellen, dass das Fach “Digitale Welt” nicht nur theoretisch, sondern auch praktisch erlebbar wird und die Schüler optimal auf die digitale Zukunft vorbereitet werden.

Weitere Informationen, auch zur Anmeldung, finden sie in unserer Edumap

https://he.edumaps.de/59904/311745/wdvryaikhd/2nja0k8b25

Dieser kurze Text soll zeigen, wie man schnell ins Fediverse kommt. Zur Vereinfachung am Beispiel von Mastodon. Je nach gewünschtem Einsatz gibt es andere Dienste, in der Regel sind diese NICHT komplizierter in der Nutzung und Einrichtung. [Der Text basiert auf dem “QUICK START – New people start here!” von https://fedi.tips/ – dort gibt es viel detailliertere Hilfe und weitere Links. Wer die Links unten anklickt, wird dorthin weitergeleitet. Inhalte dann in englischer Sprache. Ebenfalls ausführlich und in Deutsch gibt es Anleitung bei Neles Ebildungslabor und bei Thomas Ebinger ]

In 7 1⁄2 Schritten zum Ziel

oder die ganz schnelle Variante 1. – 2. – 3. und schon kannst du loslegen. Alle weiteren Schritte gehen auch später.

1. Wähle einen Server und melde dich an: Für einen schnellen Start gehst du am besten auf die Seite https://joinmastodon.org/. Dort kannst du oben rechts die Anzeigesprache auswählen und unten mit drei Schritten einen Server finden: Anderen Server auswählen ⇒ Region = Europa ⇒ Sprache = Deutsch. Es wird eine Auswahl an Servern angezeigt. Bei einigen kann man sich jetzt direkt anmelden und loslegen, bei den anderen wird die Anmeldung vom Adminteam erst noch bestätigt. Lass dich nicht stressen, wenn du dich für einen Server entscheidest, du kannst dein Konto später jederzeit auf einen anderen Server übertragen. Noch schneller und um dir die Auswahl zu erleichtern hier 3 Server, die stabil laufen und aktiv betreut werden:
   • troet.cafe – Eine der größten deutschsprachigen Instanzen
   • bildung.social – Bildungsmenschen
   • hessen.social – Hessenmenschen
2. Fülle dein Profil aus: Das ist der leichteste Teil – Schreib ein paar Worte über dich, wer du bist, was du machst, welche Interessen & Hobbys du hast und wie du gerne angesprochen werden möchtest. Im Fediverse interessieren sich die Menschen füreinander ;–)

3. Entdecke Personen, denen du folgen kannst: Dieser Teil ist etwas anders als üblich, denn es gibt im Fediverse keinen Algorithmus, der dir schon mal eine Liste von Menschen vorschlägt. Das ist ungewohnt, sorgt aber dafür, dass sich Hass und Hetze nicht ausbreiten können. Es geht nicht um Aufmerksamkeit, sondern Austausch. Wie ich ja schon geschrieben habe: ungewohnt. Am einfachsten: Du kennst (sicher) schon ein paar Menschen und sie schicken dir ihre Adresse. Der Aufbau dieser Adresse ist @benutzername@servername. Das gibst du ins Suchfeld ein, bekommst das Profil der Person angezeigt und drückst “Folgen”. Da das etwas mühsam ist, gibt es eine andere Lösung: fertige Startpakete. Diese kannst du nach Themen durchsuchen und dann auf einen Schlag eine ganze Liste von Personen “importieren”, heißt mit einem Klick folgen. Die Funktion ist noch recht neu, es gibt aber bereits einige gute Pakete, z.B. zum Thema Bücher oder auch Fotografie oder Elektronik oder auch Bildung. Der Sender 3Sat hat ein Paket mit Empfehlungen zum Thema Nachrichten erstellt.

   Das war es

   schon kannst du loslegen. Schau dich um und wenn du ein gutes Gefühl hast, machst du mit den nächsten Punkten weiter. Wenn du Hilfe brauchst, frag einfach. Ab hier kommen jetzt die Schritte, die dafür sorgen, dass du dich darauf freust im Fediverse zu sein

4. Wähle eine App oder nutze die Website deines Servers oder die Web-App: Apps für Android und iOS gibt es in den jeweiligen Stores. Weit verbreitet sind die Apps “Mastodon”, “Megalodon” und “Tusky” für Android sowie “Mastodon”, “Ivory” und “Ice Cubes” für iOS. Dabei handelt es sich nur um Empfehlungen, es gibt für beide Plattformen weiter Apps. Du kannst natürlich nach der Anmeldung einfach die Website des Servers im Browser nutzen. Mastodon im Original sozusagen. Damit kann man schon viel anfangen und durch einzelne Einstellungen zu einem sehr komfortablen Nutzererlebnis kommen. Aber auch für den Browser gibt es sogenannte Web-Apps, das erklärt dann der weiterführende Beitrag im Original.

5. Folge einigen Hashtags und folge einigen Gruppen: Je nachdem, wie du Mastodon (oder auch andere Fediverse Dienste) nutzt, hast du verschiedene Möglichkeiten der Suche. In der Regel gibt es sowohl im Browser als auch in den Apps ein Suchfeld. Dort kannst du z.B. nach einem Hashtag (das Ding mit der Raute “#” vorne dran) suchen. Wenn du aus der Trefferliste deinen Hashtag oder einen passenden ähnlichen auswählst, hast du die Möglichkeit durch einfaches Anklicken, diesem zu folgen. Ab diesem Moment werden alle Beiträge in deiner Timeline/auf deiner Startseite angezeigt. Kleine Übung: Folge dem Hashtag #neuHier Das mit den Gruppen lassen wir in diesem Schnelleinstieg mal weg, klick auf den Link und du findest eine gute Erklärung. Eine Bemerkung aber vorab: Es ist nicht, wie du z.B. Gruppen von Facebook kennst. Zumindest nicht bei Mastodon.

6. Einige Tipps, damit dein Konto und deine Beiträge leichter entdeckt werden: Um es kurz zu machen – Du bist der Algorithmus, d.h. du bist sowohl dafür verantwortlich, was du siehst, als auch dafür, wie gut du gesehen wirst. Einen ersten Tipp gab es oben schon: Schreib was in dein Profil. Aber es gibt noch ein paar wichtige Tricks, wie du dafür sorgst, dass dich andere finden und dir dann evtl. sogar folgen.

   • Nutze den Hashtag #neuHier für deinen ersten Beitrag. Und erzähle was über dich. Viele beobachten diesen Hashtag – du ja auch ;–), teilen deinen ersten Beitrag gerne und sorgen so dafür, dass man dich sofort sieht.
   • Bei deinen Beiträgen kannst du einstellen, wer dich sieht. Am einen Ende alle (Öffentlich) am anderen Ende nur die erwähnten anderen Benutzer (nur ausgewählte Profile). Dazwischen gibt es weitere Abstufungen Natürlich gibt es weitere Tipps, wenn du dem Link folgst

7. Teile deine Kontoadresse mit Freunden, damit sie dir folgen können: Das erklärt sich von selbst: Wenn du dein Profil eingerichtet hast, gehst zurück zu der Plattform, von der du wegwechselst und schreibst dort, unter welchem Namen (neudeutsch “Handle”) du im Fediverse gefunden werden kannst. Denn im Unterschied zu den geschlossenen Systemen der kommerziellen Anbieter kann man auch Profile über die verschiedenen Dienste hinweg finden und ihnen folgen. Aber Achtung: Offensichtlich verstehen die großen Anbieter da wenig Spaß und neigen dazu, deinen Beitrag als “Spam” zu markieren und nicht anzuzeigen. Wenn das passiert, hast du alles richtig gemacht: Du verlässt ein geschlossenes System, das versucht, seine Nutzer mit aller Gewalt festzuketten.

8. Wenn du ein offizielles Konto für eine Person oder Organisation hast, möchtest du vielleicht dein Konto verifizieren, damit die Leute wissen, dass es offiziell ist: Na ja, du weißt jetzt schon so viel, wenn du das machen möchtest, folgst du am besten dem Link. Besser wäre aber, du fängst jetzt gleich an. Bei Schritt 1 :–)

#Fediverse #Mastodon #neuHier #Quickstart #Anleitung #Tutorial #eXit

Von Netzwerken und Netzwerken

Seit einigen Tagen wird im Fediverse heftig über die Interpretation bzw. die Definition gekämpft. Von “Netzwerk”. Aber auch ein bisschen von “Fediverse”.
Wie so oft im digitalen Austausch auf den unterschiedlichsten Plattformen treffen bei solchen Diskussionen schnell 2 Parteien aufeinander: die Eingeborenen (Hardcore IT Nerds, schon immer dabei und etwas sperrig im Umgang mit anderen Menschen – naturgegeben :–) ) und die Zugezogenen (natürlich vor allem aus Sicht der Eingeborenen), die die Dinge einfach nur nutzen wollen, ohne lange Belehrungen auskommen möchten und kein Interesse haben etwas “von Grund auf” zu verstehen. Es muss funktionieren, basta. Du Anbieter, ich Konsument.
In so einer Umgebung wird schnell aneinander vorbeigeredet und die eine Partei wirft der anderen nach knapp 42 Sekunden vor, keine Ahnung zu haben. Oder kein Interesse.
Deshalb hier mal ein Versuch der Einordnung und evtl. auch die Korrektur verschiedener Fehlannahmen.

Die Begriffe

Zuerst müssen wir einige grundlegende Begriffe klären.

• Sozial: (https://de.wiktionary.org/wiki/sozial)
  

Bedeutungen: [1] die Gesellschaft betreffend, menschliches Miteinander betreffend [2] hilfsbereit, mitmenschlich denkend

• Medien (digital): (https://de.wikipedia.org/wiki/Digitale_Medien)

im weitesten Sinne bereitgestellte, elektronische Präsentations- und Darstellungsformate, in denen Informationen in digitaler Form verarbeitet und übertragen werden.

• Netzwerk: (https://de.wikipedia.org/wiki/Netzwerk)

interdisziplinäre Systeme, deren zugrundeliegende Struktur sich mathematisch als Graph modellieren lässt und die über Mechanismen zu ihrer Selbstorganisation verfügen.

Der Baukasten

Nachdem wir die einzelnen Wortbedeutungen geklärt haben, bauen wir das Ganze schrittweise zusammen. Fangen wir vorn an, mit der Kombination von “Sozial” und “Medien”. Das gibt in der Summe – inkl. einer einfachen Übersetzung der beiden Wörter in eine andere Sprache – “Social Media” oder dann doch auf Deutsch “Soziale Medien”. Da es nicht damit getan ist, zwei Begriffe hintereinander zu schreiben und damit ihre Bedeutung zusammenzufügen, gilt es herauszufinden, wie denn nun die Definition für den neu geschaffenen Begriff lautet. Auch an dieser Stelle wieder ein Quell schier unerschöpflicher Information: die Wikipedia-Enzyklopädie (https://de.wikipedia.org/wiki/Soziale_Medien). Und da stehen zwei Sätze, die uns schnell voranbringen werden

Soziale Medien oder englisch Social Media sind digitale Medien bzw. Plattformen (Social Software), die es Nutzern ermöglichen, sich im Internet zu vernetzen, sich also untereinander auszutauschen und mediale Inhalte einzeln, in einer definierten Gemeinschaft oder offen in der Gesellschaft zu erstellen, zu diskutieren und weiterzugeben.

und

Der verbreitetste und bekannteste Typ von sozialen Medien sind die sozialen Netzwerke.

Im ersten Satz finden wir das Wort “vernetzen”, also schon mal ein Schritt in die richtige Richtung. Spannend wird es aber im zweiten Satz: 2 unserer Wörter, die wir bisher nicht kombiniert hatten, werden hier zusammengebracht. “Sozial” und “Netzwerk” ergeben ein “Soziales Netzwerk”. Huh, it's magic!
Gibt es da auch etwas von Ratiopharm? Unter Umständen, aber auch da werden wir natürlich bei der Wikipedia fündig:

“Ein soziales Netzwerk ist ein Onlinedienst, der die Möglichkeit zu Informationsaustausch und Beziehungsaufbau bietet. Eine dadurch entstehende Online-Community bietet computervermittelte Kommunikation und digitale soziale Interaktion entsprechend den Möglichkeiten der jeweiligen Social Software (Plattform)”

Die Diskussion

An dieser Stelle beginnt das Problem. Denn nun werden plötzlich 2 verschiedene Bedeutungen des Wortes Netzwerk durcheinander geworfen. Und wie es im Internet nicht unüblich ist, hört keine Seite der anderen zu oder versucht herauszubekommen, ob man unter Umständen aneinander vorbeiredet. Man erklärt sich lieber gegenseitig, wie die Welt funktioniert, und beide Parteien wissen sicher, dass nur sie recht haben. Nie die anderen. Weil. Richtig unterhaltsam wird es, wenn eine der beiden Parteien dann nicht nur auf ihrem Standpunkt beharrt, sondern diesen auch noch mit griffigen Wortschöpfungen aus den Marketingabteilungen des Internets belegt. Deshalb jetzt schrittweise.

1. Das Wort “Netzwerk” beschreibt zuallererst Graphen, die aus Knoten und Kanten bestehen. Wenn man die Knoten mit Kanten auf die richtige Art und Weise verbindet, erhält man Maschen. Netzwerke zeichnen sich dadurch aus, das ein Großteil der Knoten zu einer oder mehreren Maschen gehört. Das zur Theorie.
2. In der physischen Realität, in diesem Fall in der Welt der Technik und Nerds, heißt das, wenn man Netzwerkgeräte wie Server (Knoten) über Kabel (Kanten) verbindet, hat man ein Netzwerk. Eines davon kennen wir alle, es heißt schlicht “Internet”. Auf diesem Internet werden die unterschiedlichsten Angebote transportiert, dazu verwendet man sogenannte Protokolle. Eines dieser Protokolle heißt “https” und wird für das WWW, das World Wide Web (Vorsicht, da steckt schon wieder das Wort “Netz” drin und meint tatsächlich ein logisches Netz), verwendet. Also zur Anzeige von “seitenbasierten” Informationen. Ein anderes Protokoll heißt “smtp” und macht genau das, was die Auflösung des Akronyms verspricht. Das “Simple Mail Transfer Protocol” wird vor allem zum Versenden von Mails verwendet. Beide Protokolle setzen dezentrale Strukturen um. Jetzt zum Stein des Anstoßes, das Protokoll “ActivityPub”. ActivityPub ist ein relativ junges Protokoll und es wurde mit dem Wunsch entworfen, zukünftige “Soziale Netzwerk” nicht über einen zentralen Server zu organisieren, sondern dezentrale Strukturen zu realisieren. Ui, bei “dezentrale soziale Netzwerke” fängt der Kopf an, etwas wehzutun? Kein Problem, wir sind auf einem guten Weg.
3. Es gibt noch eine weitere “Realität”, die gesellschaftliche. Auch dort bilden wir Netzwerke. Ob es unser Dorf ist, das Unternehmen, in dem wir arbeiten oder die Schule, in die wir gehen. Überall haben wir Peers (andere Knoten), mit denen wir in Interaktion treten, das heißt auf die eine oder andere Art verbunden sind (Kanten). Verlegen wir diese Netzwerke im echten Leben ins Internet, müssen wir uns nur kurz an die Definition erinnern “soziales Netzwerk” –> “Onlinedienst” –> Informationsaustausch und Beziehungsaufbau” –> “Online-Community” –> “computervermittelte Kommunikation und digitale soziale Interaktion”. Bämm, “Social Network” ist nix anderes als die Beschreibung eines gesellschaftlichen Netzwerks in Digital.

Die Summe der Teile

So, wir haben jetzt eine gute Grundlage. Offensichtlich kann man das Wort Netzwerk mit verschiedenen Bedeutungen verwenden. Physikalische Netze, logische Netze (die auf den physikalischen Netzen aufbauen) und gesellschaftliche/soziale Netze. WWW und Mail sind schon immer dezentral aufgebaut, die sogenannten “Soziale Medien” wie Facebook, Xitter und Co. sind jedoch zentral organisiert.
Eines der neueren dezentralen Netzwerke ist das sogenannte “Fediverse” (https://de.wikipedia.org/wiki/Fediverse). Es besteht aus vielen weiteren unabhängigen Netzwerken (Achtung, wir reden jetzt schon wieder über zwei verschiedene Arten von Netzwerk: Protokoll (ActivityPub) und Dienste des Servers), die durch einen “Föderation” genannten Mechanismus Daten austauschen können. Das ermöglicht etwas Einmaliges: Im Unterschied zu “Sozialen Netzwerken”, die auf einem zentralen Anbieter basieren und einen Austausch untereinander mit allen Mitteln verhindern, ist es im Fediverse egal, auf welchem Server ich mich anmelde. Ich kann mich (in den meisten Fällen) trotzdem mit Benutzern auf anderen Servern und Plattformen austauschen und vernetzen. Auf die “alte” Welt übertragen bedeutet das, dass ich mit einem TikTok Account den Beiträgen eines Facebook-Accounts folgen und auf diese auch reagieren kann.

Klingt komisch, ist es aber nicht.

Besser, es gibt im Fediverse nämlich nicht nur einen Facebook-Server, sondern viel davon. Es gibt nicht nur einen Instagram-Server, sondern viele davon. Und nachdem jetzt auch die letzten Aufrechten den Microblogging-Dienst Xitter verlassen haben, stellen sie fest, es gibt nicht nur einen Server mit vergleichbarem Angebot, sondern viele davon. Physikalisch nutzen alle das gleiche “Kabel” und ein gemeinsames Protokoll, bieten aber unterschiedliche Schwerpunkte. Bilder, Videos, Blogbeiträge, Kurznachrichten, Diskussionsgruppen. Name it, you'll find it.
“Ja, aber, das sind doch ganz viele verschiedene Netzwerke!” höre ich euch rufen. Das stimmt. Oder auch nicht. Wenn man sich die Seiten der jeweiligen Dienste anschaut, gibt es dort unterschiedliche Arten, wie sie sich selbst beschreiben. Einige nennen sich “Plattform”, andere reden von “Dienst” und ja, einige bezeichnen sich als Netzwerk. Und zwar im Sinne von “Social Network”, also einer Plattform zur Abbildung von sozialen Interaktionen. Das hat aber nicht mit dem Kabel und Protokoll zu tun, das dafür genutzt wird, sondern verwendet nur den Begriff des gesellschaftlichen Konstrukts eines Netzwerks von miteinander verbundenen Menschen. Und es ist vielleicht der etwas tapsige Versuch, den wechselwilligen Nutzern der monolithischen Angebote durch bekannte Begrifflichkeiten zu zeigen, dass es hier auch schön ist. Hier im Fediverse, denn dort ist dieser Beitrag zu finden. Und der Kanal auf diesem Server kann von allen anderen Nutzern im Fediverse abonniert und in ihrer eigenen Timeline mitgelesen werden. Das muss dann nicht zwingend bei Mastodon sein, dort sind halt in den letzten Jahren die meisten Menschen gelandet.
War doch ganz einfach, oder?
(ursprünglich erschienen unter https://text.tchncs.de/makeratschool/von-netzwerken-und-netzwerken)

​