Der Zeitpunkt ist nicht zufällig. Am 15. Oktober 2026 erscheint Forgejo 17, zwei Wochen später endet der Support für Forgejo 16. Wer jetzt einsteigt, sollte deshalb wissen, welche Version er in die Compose-Datei schreibt, bevor er sie schreibt. Die Grundlagen zu Docker stehen in Docker Basics und Installation, sie werden hier nicht wiederholt.

Forgejo selbst hosten: was ihr bekommt

Forgejo ist eine sogenannte Forge: eine Weboberfläche rund um Git, die aus nackten Repositories eine Arbeitsumgebung macht. Dazu gehören Issues, Pull Requests, ein Wiki, Releases, Organisationen mit Teams und ein Paketregister. Git selbst bleibt dabei unverändert; Forgejo verwaltet nur, wer worauf zugreifen darf und was drumherum passiert.

Die Software hat eine Vorgeschichte, die ihren Charakter erklärt. Forgejo entstand im Oktober 2022 als Abspaltung von Gitea, nachdem ein kommerzielles Unternehmen die Domains und die Marke von Gitea übernommen hatte, ohne die Gemeinschaft zu fragen. Anfang 2024 wurde daraus ein Hard Fork, seither entwickeln sich beide Codebasen auseinander. Getragen wird Forgejo vom gemeinnützigen Verein Codeberg e.V. Mit Version 9.0 hat das Projekt ausserdem die Lizenz von MIT auf GPLv3+ umgestellt, mit der Begründung: "Copyleft licenses do not only benefit the developers. They also guarantee freedoms to users of the software."

Warum überhaupt weg von GitHub? GitHub gehört seit dem Kauf im Juni 2018 für 7,5 Milliarden Dollar Microsoft und unterliegt damit dem US-Recht, das wir in Der CLOUD Act: Eure Daten und die amerikanische Software ausführlich beschrieben haben. Für ein öffentliches Open-Source-Projekt mag das verschmerzbar sein. Für private Repositories mit Konfigurationen, Notizen und halbfertigen Ideen ist es eine andere Frage.

Was diese Anleitung bewusst nicht abdeckt, ist Forgejo Actions, das eingebaute CI-System. Es führt Workflows nicht selbst aus, sondern übergibt sie an separate Runner, und ist an GitHub Actions angelehnt, ohne auf Kompatibilität ausgelegt zu sein. Das ist ein eigenes Thema mit eigenen Sicherheitsfragen.

Welche Version: Forgejo LTS oder die stabile Reihe

Forgejo veröffentlicht alle drei Monate eine neue Hauptversion, und die jeweils erste des Jahres ist eine LTS-Version mit längerem Support. Der offizielle Release-Zeitplan nennt für die nächsten Monate folgende Daten:

• Forgejo 15.0 (LTS): erschienen am 16. April 2026, Support bis 15. Juli 2027
• Forgejo 16.0: erschienen am 16. Juli 2026, Support bis 29. Oktober 2026
• Forgejo 17.0: geplant für den 15. Oktober 2026, Support bis 28. Januar 2027
• Forgejo 19.0 (LTS): geplant für den 15. April 2027

Stand heute sind laut der Release-Übersicht Forgejo 16.0.5 und die LTS-Fassung 15.0.9 aktuell, beide vom 17. September 2026.

Für einen Server, den ihr nebenher betreibt, ist die LTS-Reihe die vernünftige Wahl. Die Docker-Installationsseite von Forgejo hält fest, dass der Sprung von einer Hauptversion zur nächsten, etwa von 12 auf 13, "a manual operation and human verification" verlangt. Mit der stabilen Reihe steht diese Handarbeit viermal im Jahr an, mit der LTS-Reihe einmal. Wer neue Funktionen sofort haben will, nimmt die stabile Reihe und plant die Quartalsupdates fest ein; alle anderen schreiben den Tag 15 in die Compose-Datei und bekommen Fehlerbehebungen und Sicherheitskorrekturen automatisch.

Ein Punkt spricht zusätzlich für Gelassenheit: Forgejo 16 ist ausdrücklich "a non-LTS release". Wer jetzt auf 16 einsteigt, muss in vier Wochen ohnehin auf 17 wechseln.

Voraussetzungen für den eigenen Git-Server

Ihr braucht einen Linux-Server mit Docker und dem Compose-Plugin aus dem offiziellen Docker-Repository. Achtung: Die Installationsanleitung in unserem Docker-Grundlagenartikel installiert das Compose-Plugin nicht mit. Holt es laut Docker-Dokumentation nach und prüft die Version:

sudo apt-get update
sudo apt-get install docker-compose-plugin
docker compose version

Dazu kommen eine Domain oder Subdomain, die auf euren Server zeigt, in dieser Anleitung git.example.ch, sowie ein laufendes Caddy. Feste Hardwareanforderungen nennt die offizielle Forgejo-Dokumentation nicht.

An Ports werden gebraucht: 80 und 443 für Caddy, wie gehabt, und 222 für Git über SSH. Port 22 bleibt für den SSH-Zugang zum Server selbst reserviert. Wer den Server über das Internet erreichbar macht, gibt Port 222 in der Firewall frei; wer Forgejo nur im Heimnetz oder über Wireguard nutzt, lässt ihn zu.

Kurz vor dem Loslegen noch ein Wort zur eigenen Motivation: Einen eigenen Git-Server aufzusetzen, um ein Dotfiles-Repository mit drei Commits zu hosten, ist klassische Selfhosting-Überdimensionierung. Wir machen es trotzdem, aus Prinzip.

Die Compose-Datei: Forgejo mit SQLite

Die Forgejo-Dokumentation empfiehlt in ihren Konfigurationsempfehlungen für Instanzen mit geringer bis mittlerer Last ausdrücklich SQLite, weil sie einfach ist, keine Wartung braucht und als eine einzige Datei auf der Platte liegt. PostgreSQL oder MySQL empfiehlt sie erst für viel Betrieb. Für einen privaten Git-Server heisst das: Ein Container genügt.

Legt ein Verzeichnis an und prüft, welche Benutzer- und Gruppen-ID euer Konto hat:

sudo mkdir -p /opt/forgejo
sudo chown $USER: /opt/forgejo
cd /opt/forgejo
id -u
id -g

Die beiden Zahlen gehören gleich in die Compose-Datei. Auf den meisten Einzelplatzsystemen ist es 1000. Legt nun /opt/forgejo/compose.yml mit folgendem Inhalt an:

networks:
  forgejo:
    external: false

services:
  server:
    image: codeberg.org/forgejo/forgejo:15
    container_name: forgejo
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - FORGEJO__server__DOMAIN=git.example.ch
      - FORGEJO__server__ROOT_URL=https://git.example.ch/
      - FORGEJO__server__SSH_DOMAIN=git.example.ch
      - FORGEJO__server__SSH_PORT=222
      - FORGEJO__server__SSH_LISTEN_PORT=22
    restart: always
    networks:
      - forgejo
    volumes:
      - ./forgejo:/data
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "127.0.0.1:3000:3000"
      - "222:22"

Der Aufbau folgt dem Beispiel aus der Docker-Installationsseite von Forgejo, mit drei Änderungen: dem Tag 15 statt 16, den Servereinstellungen als Umgebungsvariablen und der Bindung von Port 3000 an 127.0.0.1.

Was die einzelnen Zeilen tun

USER_UID und USER_GID legen fest, unter welcher ID Forgejo im Container läuft. Die Dokumentation verlangt, dass das Datenverzeichnis genau diesem Benutzer gehört. Stimmt das nicht, startet der Container nicht sauber.

Die Variablen mit FORGEJO__ am Anfang sind Einträge in der Konfigurationsdatei app.ini, geschrieben nach dem Muster FORGEJO__abschnitt__SCHLÜSSEL. So bleibt die gesamte Konfiguration in einer Datei, die ihr versionieren und sichern könnt. Eine Einschränkung nennt die Dokumentation selbst: Einen bestehenden Wert könnt ihr über Umgebungsvariablen nicht löschen, nur überschreiben.

ROOT_URL ist die Adresse, unter der Forgejo von aussen erreichbar ist, und damit die Grundlage jedes Links, den Forgejo erzeugt. SSH_PORT ist laut Konfigurationsreferenz der Port, der in der Klon-Adresse erscheint. Ohne diese Zeile zeigt Forgejo Adressen mit Port 22 an, die bei euch ins Leere laufen. SSH_LISTEN_PORT gilt für den eingebauten SSH-Server; das Standard-Image benutzt stattdessen OpenSSH im Container auf Port 22. Die Zeile ist eine Absicherung dafür, dass niemand später die beiden Ports verwechselt.

Die Portzeile 127.0.0.1:3000:3000 sorgt dafür, dass die Weboberfläche nur auf dem Server selbst erreichbar ist. Von aussen führt der Weg ausschliesslich über Caddy. Die Zeile 222:22 leitet Port 222 des Servers auf den SSH-Dienst im Container weiter.

Wann ihr doch PostgreSQL nehmt

Plant ihr eine Instanz für einen Verein oder ein Team mit regem Betrieb, ergänzt ihr einen Datenbankdienst. Die Docker-Seite von Forgejo zeigt dafür diese Erweiterung, die in environment des Forgejo-Dienstes und als zweiter Dienst dazukommt:

      - FORGEJO__database__DB_TYPE=postgres
      - FORGEJO__database__HOST=db:5432
      - FORGEJO__database__NAME=forgejo
      - FORGEJO__database__USER=forgejo
      - FORGEJO__database__PASSWD=ein-langes-zufallspasswort

  db:
    image: postgres:14
    restart: always
    environment:
      - POSTGRES_USER=forgejo
      - POSTGRES_PASSWORD=ein-langes-zufallspasswort
      - POSTGRES_DB=forgejo
    networks:
      - forgejo
    volumes:
      - ./postgres:/var/lib/postgresql/data

Beim Forgejo-Dienst kommt zusätzlich depends_on: [db] hinzu. Das Passwort muss an beiden Stellen identisch sein. Die Dokumentation verwendet in ihrem Beispiel forgejo als Passwort; übernehmt das nicht.

Erster Start und das Administratorkonto

Legt das Datenverzeichnis an, übergebt es der ID aus der Compose-Datei und startet den Container:

mkdir -p /opt/forgejo/forgejo
sudo chown -R 1000:1000 /opt/forgejo/forgejo
docker compose up -d
docker compose logs -f server

Wenn die Logs zur Ruhe kommen, beendet ihr sie mit Strg+C. Der Container läuft weiter.

Jetzt kommt der Schritt, bei dem die Reihenfolge zählt. Laut Installationsanleitung erhält der erste registrierte Benutzer Administratorrechte. Solange Forgejo nur an 127.0.0.1 lauscht und Caddy noch nicht konfiguriert ist, kann das niemand ausser euch sein. Öffnet von eurem Rechner aus einen SSH-Tunnel zum Server:

ssh -L 3000:127.0.0.1:3000 benutzer@euer-server

Ruft dann im Browser http://localhost:3000 auf. Forgejo zeigt beim ersten Aufruf eine Seite mit der Grundkonfiguration. Prüft dort, dass Datenbanktyp SQLite3, Server-Domain, SSH-Port 222 und die Basis-URL https://git.example.ch/ stimmen, und schliesst die Installation ab. Registriert danach sofort euer eigenes Konto. Es wird das Administratorkonto.

Anschliessend sperrt ihr die offene Registrierung, bevor die Instanz von aussen erreichbar wird. Ergänzt in der Compose-Datei unter environment:

      - FORGEJO__service__DISABLE_REGISTRATION=true
      - FORGEJO__service__DEFAULT_KEEP_EMAIL_PRIVATE=true

Die zweite Zeile blendet die E-Mail-Adressen neuer Konten standardmässig aus. Wollt ihr, dass ohne Anmeldung überhaupt nichts sichtbar ist, auch keine öffentlichen Repositories, kommt FORGEJO__service__REQUIRE_SIGNIN_VIEW=true dazu. Übernehmt die Änderung mit:

docker compose up -d

Compose erkennt die geänderte Umgebung und erstellt den Container neu. Weitere Konten legt ihr ab jetzt als Administrator in der Verwaltungsoberfläche an. Schaltet für euer eigenes Konto gleich die Zwei-Faktor-Authentifizierung ein: Forgejo unterstützt laut Codeberg-Dokumentation TOTP und zusätzlich Hardwareschlüssel über WebAuthn, eingerichtet in den Benutzereinstellungen unter Sicherheit. Den dabei angezeigten Wiederherstellungscode legt ihr in euren Passwortmanager.

HTTPS über Caddy

Mit Caddy ist der Reverse Proxy für Forgejo eine Sache von drei Zeilen. Ergänzt in /etc/caddy/Caddyfile den Block, den auch die Forgejo-Dokumentation zum Reverse Proxy zeigt:

git.example.ch {
	reverse_proxy 127.0.0.1:3000
}

Prüfen und neu laden wie gewohnt:

sudo caddy fmt --overwrite /etc/caddy/Caddyfile
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

Caddy holt das Zertifikat selbst und setzt die Kopfzeilen X-Forwarded-For und X-Forwarded-Proto ohne weiteres Zutun. Eine Obergrenze für die Uploadgrösse setzt Caddy nicht; wer stattdessen nginx benutzt, braucht die in der Forgejo-Dokumentation genannte Zeile client_max_body_size 512M;, sonst scheitern grosse Pushes über HTTPS und Anhänge.

Ein Detail betrifft alle, die später auf Forgejo 17 oder die nächste LTS wechseln. Mit Forgejo 16 hat das Projekt die Voreinstellung für vertrauenswürdige Proxys in Container-Installationen verschärft. Die Release-Notiz nennt als Folge, dass Forgejo eine Anmeldung über Kopfzeilen des Reverse Proxy nicht mehr akzeptiert, wenn diese Funktion eingeschaltet ist, und verlangt eine ausdrückliche Liste mit dem Adressbereich des Container-Netzes. In der Konfiguration heisst der Schlüssel REVERSE_PROXY_TRUSTED_PROXIES im Abschnitt [security]. Wer diese Anmeldung nicht nutzt, wie in dieser Anleitung, ist davon nicht betroffen.

Sitzt der Proxy, ist die Weboberfläche unter https://git.example.ch erreichbar. Das war der unspektakuläre Teil. Wer bis hierhin gekommen ist, hat einen Git-Server, der sich im Browser nicht von einem gemieteten unterscheidet, nur dass ihn niemand mit einer KI-Funktion beglücken wird, um die ihr nicht gebeten habt.

Git über SSH auf Port 222

Damit Git über SSH funktioniert, braucht Forgejo euren öffentlichen Schlüssel. Wer noch keinen hat, findet die Grundlagen in Sicher per SSH einloggen. Hinterlegt den Inhalt eurer ~/.ssh/id_ed25519.pub in Forgejo unter Einstellungen, SSH-/GPG-Schlüssel.

Testet dann die Verbindung mit dem Befehl aus der Forgejo-Dokumentation:

ssh -F /dev/null git@git.example.ch -p 222

Der Parameter -F /dev/null sorgt dafür, dass eure lokale SSH-Konfiguration beim Test keine Rolle spielt. Forgejo antwortet mit einer kurzen Meldung, die euren Benutzernamen nennt, und schliesst die Verbindung wieder. Eine Shell gibt es an dieser Stelle nicht, und das ist richtig so.

Damit ihr nicht bei jedem Befehl den Port angeben müsst, ergänzt ihr auf eurem Rechner die Datei ~/.ssh/config:

Host git.example.ch
    Port 222
    User git
    IdentityFile ~/.ssh/id_ed25519

Ab jetzt funktionieren Klon-Adressen in der Form, die Forgejo selbst anzeigt:

git clone ssh://git@git.example.ch:222/mario/dotfiles.git

Dank des Eintrags in ~/.ssh/config klappt auch die kürzere Schreibweise git@git.example.ch:mario/dotfiles.git.

Wer über HTTPS statt SSH arbeitet und die Zwei-Faktor-Authentifizierung eingeschaltet hat, meldet sich bei Git nicht mit dem Passwort an, sondern mit einem Zugriffstoken, das ihr in den Einstellungen unter Anwendungen erzeugt.

Von GitHub umziehen: Migration und Spiegel

Forgejo kann bestehende Repositories von GitHub, GitLab und anderen Forges übernehmen. Der Weg führt über das Plus-Menü oben rechts und den Eintrag "Neue Migration". Dort wählt ihr GitHub als Quelle und gebt die Adresse des Repositories an.

Für mehr als den nackten Git-Verlauf braucht Forgejo ein persönliches Zugriffstoken von GitHub. Laut Codeberg-Dokumentation zur Migration lassen sich damit auch Metadaten wie Issues, Labels, Wiki, Releases und Meilensteine mitnehmen. Gebt dem Token nur Leserechte und widerruft es nach dem Umzug wieder. Für private Repositories ist es ohnehin nötig, weil Forgejo sonst gar keinen Zugriff hat.

Nicht jeder will GitHub sofort verlassen. Für den Übergang bietet Forgejo zwei Arten von Spiegeln:

• Ein Pull-Spiegel holt regelmässig den Stand eines fremden Repositories in eure Instanz. Er lässt sich nur beim Anlegen eines neuen Repositories einrichten, über dieselbe Migrationsmaske mit dem Häkchen für den Spiegel.
• Ein Push-Spiegel schiebt jeden Stand eures Forgejo-Repositories zu GitHub. Damit wird Forgejo zur führenden Quelle und GitHub zur Kopie. GitHub verlangt dafür ein Token mit dem Recht public_repo, optional zusätzlich workflow.

Beim Push-Spiegel ist die Warnung der Dokumentation ernst zu nehmen: Er schiebt mit Force Push und überschreibt alles, was am Ziel abweichend liegt. Wer auf GitHub noch direkt arbeitet, verliert dort Commits. Die Regel lautet deshalb: Es gibt genau eine Stelle, an der gearbeitet wird, und die andere ist Kopie.

Issues und Labels werden bei einem Pull-Spiegel übrigens nicht mitgespiegelt, wie ein Fehlerbericht im Forgejo-Projekt festhält: Beim Häkchen für den Spiegel sind die Optionen für Issues, Pull Requests und Releases gesperrt, das Projekt führt das als nicht umgesetzte Funktion. Gespiegelt wird der Git-Inhalt. Wer die Diskussionen mitnehmen will, macht eine echte Migration.

Sichern und zurückspielen

Forgejo bringt mit forgejo dump einen eigenen Sicherungsbefehl mit, der alles in ein Archiv packt. Die Upgrade-Anleitung von Forgejo warnt allerdings selbst, dass das Zurückspielen der Datenbank aus diesem Archiv "serious long standing open bugs" hat. Als verlässlichsten Weg empfiehlt sie eine zeitgleiche Momentaufnahme des gesamten Speichers, den Forgejo benutzt.

Mit SQLite und einem einzigen Datenverzeichnis ist genau das einfach: Container anhalten, Verzeichnis archivieren, Container starten.

cd /opt/forgejo
docker compose stop
sudo tar -czf /srv/backup/forgejo-$(date +%F).tar.gz forgejo compose.yml
docker compose start

Die Unterbrechung dauert wenige Sekunden. Weil compose.yml mit im Archiv liegt, enthält die Sicherung auch die komplette Konfiguration. Wer PostgreSQL benutzt, nimmt das Verzeichnis postgres in den tar-Befehl mit auf und erstellt vorher, bei noch laufendem Stack, zusätzlich einen Datenbankauszug, der unabhängig von der PostgreSQL-Version lesbar bleibt:

docker compose exec -T db pg_dump -U forgejo forgejo > /srv/backup/forgejo-db-$(date +%F).sql

Das Zurückspielen ist die Umkehrung: Archiv an denselben Ort entpacken, Eigentümer mit chown -R 1000:1000 prüfen, docker compose up -d. Probiert das einmal auf einer zweiten Maschine aus, bevor ihr es braucht. Warum eine Sicherung, die nie zurückgespielt wurde, wenig wert ist, und wo die zweite Kopie hingehört, steht in Was ist ein gutes Backup: die 3-2-1-Regel erklärt. Den nächtlichen Lauf automatisiert ihr am besten mit einem systemd-Timer statt Cronjob, der euch benachrichtigt, wenn etwas schiefgeht.

Aktualisieren ohne Überraschungen

Innerhalb einer Hauptversion ist ein Update zwei Befehle:

cd /opt/forgejo
docker compose pull
docker compose up -d

Der Tag 15 zieht dabei automatisch die neueste 15.x-Fassung. Mehr Handarbeit verlangt der Wechsel der Hauptversion, bei der LTS-Reihe also im Frühjahr 2027 von 15 auf 19. Die Upgrade-Anleitung nennt dafür diese Reihenfolge:

• Release-Notizen der neuen Version lesen, insbesondere die Abschnitte zu Änderungen mit Bruch.
• Warteschlangen leeren, weil ihr Inhalt laut Dokumentation nicht garantiert rückwärtskompatibel ist.
• Vollständige Sicherung wie oben.
• Tag in compose.yml ändern, dann docker compose pull und docker compose up -d.
• Mit forgejo doctor prüfen, dass keine Probleme gemeldet werden, und die Weboberfläche von Hand durchsehen.

Die beiden Forgejo-Befehle laufen im Container, und zwar nicht als root. Forgejo verweigert das mit der Meldung, es sei "not supposed to be run as root". Die Lösung aus dem Fehlerbericht im Forgejo-Dokumentationsprojekt ist, den Befehl mit der Benutzer-ID aus der Compose-Datei auszuführen:

docker exec -u 1000 forgejo forgejo manager flush-queues
docker exec -u 1000 forgejo forgejo doctor check --all --log-file /tmp/doctor.log

Laut Anleitung dürft ihr Hauptversionen grundsätzlich überspringen. Treten dabei Fehler auf, empfiehlt sie, die Zwischenversionen einzeln zu durchlaufen und jeweils zu prüfen.

Wenn etwas nicht klappt

Der Container startet nicht oder meldet fehlende Schreibrechte. Fast immer gehört das Datenverzeichnis dem falschen Benutzer. Prüft mit ls -ln /opt/forgejo, ob forgejo der ID aus USER_UID gehört, und korrigiert mit sudo chown -R 1000:1000 /opt/forgejo/forgejo.

Die Klon-Adresse zeigt Port 22 statt 222. Die Zeile FORGEJO__server__SSH_PORT=222 fehlt oder wurde nach einer Änderung nicht übernommen. Nach jeder Änderung an der Umgebung gehört ein docker compose up -d dazu, ein blosser Neustart des Containers reicht nicht.

SSH fragt nach einem Passwort für den Benutzer git. Der Schlüssel ist in Forgejo nicht hinterlegt, oder SSH bietet einen anderen Schlüssel an. Mit ssh -v -p 222 git@git.example.ch seht ihr, welcher Schlüssel angeboten wird. Landet die Verbindung dagegen beim SSH-Dienst des Servers statt bei Forgejo, fehlt der Port: Ohne -p 222 oder den Eintrag in ~/.ssh/config klopft Git an Port 22.

Ein Forgejo-Befehl im Container meldet, er dürfe nicht als root laufen. Ihr habt docker exec ohne -u 1000 aufgerufen.

Links in E-Mails oder in der Oberfläche zeigen auf localhost:3000. ROOT_URL fehlt oder ist falsch. Die Dokumentation zum Reverse Proxy weist ausdrücklich darauf hin, dass sonst erzeugte Links kaputtgehen.

Grosse Pushes über HTTPS brechen ab. Ein vorgeschalteter nginx begrenzt die Grösse. Caddy tut das in der Grundeinstellung nicht; liegt zusätzlich ein anderer Proxy oder ein CDN davor, prüft dessen Grenze.

Nach einem Hauptversions-Update fehlen Funktionen oder die Oberfläche wirft Fehler. Zurück auf die Sicherung, alten Tag eintragen, und die Release-Notizen lesen, bevor ihr es erneut versucht. Genau deshalb steht die Sicherung in der Reihenfolge vor dem Update und nicht danach.

Fazit: Forgejo ist der kleinste Schritt weg von GitHub

Ein eigener Git-Server klingt nach Infrastrukturprojekt und ist am Ende ein Container, eine Compose-Datei und drei Zeilen Caddyfile. Forgejo nimmt euch dabei die Arbeit ab, die eine Forge ausmacht, und lässt euch die Entscheidung, wo eure Repositories liegen. Mit der LTS-Reihe hält sich auch der Pflegeaufwand in Grenzen: ein Handgriff pro Jahr für die Hauptversion, dazwischen docker compose pull.

Die Gegenrechnung gehört dazu. Auf GitHub findet euch die Welt, auf eurem Server findet euch zunächst niemand. Für öffentliche Projekte, die von Beiträgen Fremder leben, ist ein Push-Spiegel deshalb oft der ehrlichere Weg als der harte Schnitt. Für alles Private gilt dagegen: Was nie auf einem fremden Server lag, kann dort auch niemand auswerten, herausgeben oder für das Training eines Modells verwenden. Dass Forgejo seit Version 9 unter einer Copyleft-Lizenz steht und von einem gemeinnützigen Verein getragen wird, macht es ausserdem deutlich unwahrscheinlicher, dass euch in drei Jahren dieselbe Geschichte mit einer anderen Firma noch einmal passiert.

Quellen und weiterführende Links

• Forgejo: Installation with Docker
• Forgejo: Installation
• Forgejo: Release Schedule
• Forgejo: Releases
• Forgejo v16.0 is available (16.07.2026)
• Forgejo: Recommended Settings
• Forgejo: Configuration Cheat Sheet
• Forgejo: Reverse Proxy
• Forgejo: Upgrade Guide
• Forgejo: Repository Mirrors (v15.0)
• Forgejo Actions: Overview
• Forgejo: Comparison with Gitea
• Forgejo is now copyleft, just like Git (22.08.2024)
• Forgejo Docs Issue #722: Forgejo doctor can not be run as root in a container
• Forgejo Issue #4962: Pull mirroring does not mirror labels, issues
• Codeberg Documentation: Migrating repositories
• Codeberg Documentation: Setting up two-factor authentication
• Docker Docs: Install the Docker Compose plugin
• Microsoft: Microsoft to acquire GitHub for $7.5 billion (04.06.2018)

The post Forgejo selbst hosten: eigener Git-Server mit Docker appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Diese Anleitung führt von der leeren Maschine bis zur übernommenen Google-Mediathek: Voraussetzungen, Installation mit Docker Compose, die Einstellungen des ersten Tages, der Import eines Google-Takeout-Archivs ohne Datenverlust, der Zugriff von aussen und die Sicherung. Wer Immich nur ausprobieren will, findet auf yourdevice.ch eine laufende Immich-Instanz als kostenlosen Dienst. Und wer seine Bilder schon in einer Nextcloud hat, wirft vorher einen Blick auf Memories als Foto-App für Nextcloud — manchmal ist die kleinere Lösung die richtige.

Immich selbst hosten: was ihr bekommt, und was ihr nicht bekommt

Immich ist eine Galerie mit Server: Die Bilder liegen als gewöhnliche Dateien auf einer Festplatte, die Metadaten in einer Postgres-Datenbank, darüber sitzt eine Weboberfläche nach dem Vorbild von Google Fotos — Zeitleiste, Alben, Karte, Personen, Suche nach Bildinhalten. Die mobilen Apps laden neue Aufnahmen automatisch hoch, und das ist der eigentliche Grund, warum so ein Aufbau im Alltag durchhält. Ein Foto-Archiv, das Handarbeit verlangt, wird nach drei Wochen nicht mehr befüllt.

Was Immich ausdrücklich nicht ist: eine Sicherung. Die Projektdokumentation ist an dieser Stelle unmissverständlich und schreibt zum Pilotbetrieb der eigenen Datenbanksicherung: „The database only contains metadata and user information. You must setup manual backups of the images and videos stored in UPLOAD_LOCATION.“ Immich selbst empfiehlt in seiner Anleitung zu Sicherung und Wiederherstellung eine 3-2-1-Strategie. Wer die einzige Kopie seiner Familienfotos in einen Dienst schiebt, den er gerade selbst zusammengesteckt hat, hat kein Archiv, sondern ein Hobby mit Risiko.

Aktuell ist die Reihe 3.x: Version 3.0.0 erschien am 1. Juli 2026, die jüngste Fassung 3.2.0 am 10. September 2026. Mit 3.0 hat sich die Mindestanforderung an den Prozessor geändert, und die Versionsnummer steht in der Konfigurationsdatei, die ihr gleich anlegt.

Was die Maschine mitbringen muss

Die Anforderungsseite des Projekts nennt konkrete Zahlen, und sie sind ernst gemeint. Als Betriebssystem empfiehlt das Projekt „Linux or *nix 64-bit operating system (Ubuntu, Debian, etc)“; Windows und macOS gelten wegen der schwächeren Docker-Unterstützung als Notlösung. Beim Speicher stehen „Minimum 6GB, recommended 8GB“ — mit 4 GB läuft Immich nur dann, wenn das maschinelle Lernen abgeschaltet ist. Beim Prozessor sind es „Minimum 2 cores, recommended 4 cores“.

Zwei Punkte werden regelmässig übersehen. Erstens verlangt Immich ab Version 3 auf amd64 die Mikroarchitektur x86-64-v2 — das betrifft nur Rechner, die älter als etwa 2012 sind, aber wer einen ausgemusterten Bürorechner zum Fotoserver machen wollte, prüft das vorher. Zweitens gehört das Datenverzeichnis der Datenbank auf lokalen Speicher, am besten auf eine SSD: Netzwerkfreigaben sind nicht unterstützt. Das Dateisystem muss Benutzer- und Gruppenrechte kennen; NTFS und alles aus der FAT-Familie fallen damit aus.

Beim Platzbedarf rechnet ihr mit einem Zuschlag: Vorschaubilder und umgewandelte Videos lassen die Mediathek laut Dokumentation um 10 bis 20 Prozent wachsen. Bei 400 GB Bildern sind das bis zu 80 GB, die niemand einplant und die dann mitten im ersten Import die Platte füllen.

Die vier Container, aus denen Immich besteht

Immich wird nicht als ein Programm installiert, sondern als vier zusammenarbeitende Container. Der Blick in die offizielle docker-compose.yml zeigt, wer welche Aufgabe hat:

• immich-server — die Anwendung selbst, samt Weboberfläche und Schnittstelle. Sie ist das einzige Element, das einen Port nach draussen öffnet: 2283. Eingebunden ist genau ein Verzeichnis, nämlich UPLOAD_LOCATION als /data.
• immich-machine-learning — Gesichtserkennung, Objekterkennung und die Suche nach Bildinhalten. Dieser Container hält keine Nutzerdaten, sondern nur die heruntergeladenen Modelle im Volume model-cache. Er ist derjenige, der den Arbeitsspeicher frisst.
• redis — die Warteschlange für Hintergrundaufträge. Der Dienst heisst weiterhin so, das Abbild ist inzwischen aber valkey, der freie Abzweig von Redis nach dessen Lizenzwechsel.
• database — Postgres, allerdings kein gewöhnliches: Das Abbild trägt den Namen postgres:14-vectorchord… und bringt die Vektor-Erweiterungen mit, ohne die es keine Ähnlichkeitssuche und keine Gesichtsgruppierung gibt. Deshalb lässt sich hier auch nicht einfach ein bestehender Postgres-Server aus dem Netz verwenden.

Diese Aufteilung ist der Grund, warum die Sicherung später aus zwei Teilen besteht — und warum die Frage, welcher Teil des Aufbaus ersetzbar ist, vor dem ersten Import geklärt sein sollte.

Immich installieren: zwei Dateien, ein Befehl

Voraussetzung ist Docker samt Compose-Erweiterung aus dem offiziellen Docker-Repository, nicht aus den Distributionspaketen — das Projekt weist ausdrücklich darauf hin, dass Fehler beim Start meist daran liegen. Wie die Einrichtung unter Debian, Ubuntu und Linux Mint abläuft, steht in unserem Beitrag zu den Docker-Grundlagen und der Installation. Wichtig ist ausserdem die Schreibweise: docker compose mit Leerzeichen. Das alte docker-compose mit Bindestrich wird nicht mehr unterstützt.

Legt ein eigenes Verzeichnis an und holt die beiden Dateien, die das Projekt für jede Version bereitstellt:

mkdir -p /opt/immich && cd /opt/immich
wget -O docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
wget -O .env https://github.com/immich-app/immich/releases/latest/download/example.env

Die docker-compose.yml bleibt unangetastet. Bearbeitet wird nur die .env, und dort genügen fünf Zeilen:

UPLOAD_LOCATION=/srv/immich/library
DB_DATA_LOCATION=/srv/immich/postgres
IMMICH_VERSION=v3
DB_PASSWORD=EinLangesPasswortOhneSonderzeichen
TZ=Europe/Zurich

UPLOAD_LOCATION ist das Verzeichnis, in dem später alle Originale liegen. Es darf auf einer grossen Platte oder einem eingebundenen Speicher liegen. DB_DATA_LOCATION ist das Datenverzeichnis von Postgres und gehört, wie oben beschrieben, auf lokalen Speicher. Beide Pfade werden nach dem ersten Start nicht mehr geändert, ohne die Datenbank umzuziehen.

Bei DB_PASSWORD gilt eine Einschränkung, die in der Dokumentation nur als Nebensatz steht und trotzdem Installationen zerlegt: erlaubt sind ausschliesslich die Zeichen A–Z, a–z und 0–9. Ein Passwort mit Dollarzeichen oder Klammern führt zu einer Datenbank, die nicht startet, und zu einer Fehlermeldung, die das Problem nicht nennt. Nehmt eine lange Folge aus Buchstaben und Zahlen.

IMMICH_VERSION steht in der Beispieldatei auf v3. Das ist ein mitwachsendes Kennzeichen: Bei jedem docker compose pull kommt die neueste Fassung der Reihe 3.x. Wer das nicht will, schreibt eine feste Version hinein, etwa v3.2.0. Für den ersten Aufbau ist v3 richtig; sobald der Server ernsthaft benutzt wird, ist eine feste Version die ruhigere Variante.

Danach folgt der eigentliche Start:

docker compose up -d
docker compose logs -f immich-server

Der erste Start dauert länger als erwartet, weil die Datenbank ihr Schema anlegt und der Lerndienst seine Modelle herunterlädt. Erscheint eine Fehlermeldung zu start_interval im Abschnitt der Datenbank, läuft auf der Maschine eine Docker-Engine älter als Version 25; dann wird diese Zeile auskommentiert.

Der erste Aufruf und das Administratorkonto

Die Oberfläche erreicht ihr unter http://<IP-der-Maschine>:2283. Dort führt die Schaltfläche Getting Started zur Registrierung. Entscheidend ist der Satz aus der Dokumentation: „The first user to register will be the admin user.“ Wer den Port erreichbar macht, bevor er sich selbst registriert hat, verschenkt sein Administratorkonto an den ersten Besucher. Registriert euch also zuerst, und öffnet erst danach den Zugang von aussen.

Weitere Konten für Familie oder Mitbewohner legt ihr unter Administration > Users an. Ein vergessenes Administratorpasswort lässt sich laut FAQ über den Befehl reset-admin-password im Container immich-server zurücksetzen.

Die Einstellungen, die vor dem ersten Import gehören

Das Speicher-Template

Unter Administration > Settings > Storage Template legt ihr fest, wie Immich die Dateien auf der Platte ablegt. Die Vorgabe lautet Year/Year-Month-Day/Filename.Extension, die Funktion muss aber erst eingeschaltet werden. Der Sinn dahinter ist Unabhängigkeit: Eine nach Jahr und Datum sortierte Ordnerstruktur bleibt auch dann lesbar, wenn Immich eines Tages nicht mehr startet. Ohne Template liegen die Dateien unter technischen Kennungen, die ohne Datenbank nichts aussagen.

Ändert ihr das Template später, gilt es zunächst nur für neue Dateien; ein eigener Wartungsauftrag überträgt es auf den Bestand. Es ist trotzdem angenehmer, das vor dem Import der ersten 40'000 Bilder zu entscheiden.

Maschinelles Lernen dosieren oder abschalten

Gesichtserkennung und Inhaltssuche sind der Teil, der Rechenzeit und Arbeitsspeicher verlangt. Die FAQ beschreibt zwei Stufen: „Machine learning can be disabled under Administration > Settings > Machine Learning Settings, either entirely or by model type.“ Damit laufen keine Aufträge mehr — der Container startet aber weiterhin und belegt Speicher. Wer ihn ganz loswerden will, kommentiert den Abschnitt immich-machine-learning in der docker-compose.yml aus.

Bei 4 GB Arbeitsspeicher ist das der Unterschied zwischen „läuft“ und „läuft nicht“. Auch auf grösseren Maschinen lohnt es sich, die Modelle beim ersten grossen Import abzuschalten: Sonst konkurrieren Import und Analyse um dieselben Kerne.

Die App auf dem Telefon

Ohne App bleibt ein Fotoserver eine Ablage. Die Anleitung des Projekts zur Nacharbeit nach der Installation nennt vier Bezugsquellen: App Store, Google Play, die APK-Datei aus den GitHub-Releases und Obtainium sowie das F-Droid-Repository von FUTO. Für Geräte ohne Google-Dienste ist der Weg über die APK-Datei oder Obtainium der naheliegende.

Beim Anmelden wird nicht ein Konto bei einem Anbieter eingetragen, sondern die Adresse des eigenen Servers, also http://<IP-der-Maschine>:2283. Danach wählt ihr im Sicherungsbereich der App aus, welche Ordner des Telefons hochgeladen werden sollen — Kamera ja, der Ordner mit den heruntergeladenen Bildern aus Chatgruppen vermutlich nein — und schaltet die Sicherung ein. Der erste Durchlauf läuft am besten über Nacht und im WLAN.

Die Google-Fotos-Mediathek übernehmen

Jetzt zum Teil, an dem die meisten Umzüge scheitern. Ein Google-Fotos-Export ist keine Ordnerstruktur mit Bildern, sondern ein Archiv mit Bildern und einer zweiten Datei je Bild, in der die eigentlichen Informationen stehen. Wer nur die Bilder hochlädt, bekommt eine Mediathek ohne Aufnahmedaten, ohne Orte und ohne Alben — technisch vollständig, inhaltlich entkernt.

Schritt eins: das Takeout-Archiv anfordern

Der Export läuft über den Google Datenexport. Google beschreibt den Weg selbst so: Seite aufrufen, bei allen Produkten das Häkchen entfernen, die ihr nicht braucht, und nur Google Fotos stehen lassen. Danach wählt ihr Dateityp und Grösse. Nehmt ZIP, nicht TGZ, und als maximale Archivgrösse einen Wert, den euer Dateisystem und euer Download verkraften — bei 50 GB Grösse bekommt ihr wenige riesige Dateien, bei 2 GB viele kleine.

Zwei Angaben aus der Google-Hilfe sind für die Planung wichtig: Der Export kann „wenige Minuten oder auch einige Tage“ dauern, und die fertigen Archive „laufen ungefähr nach 7 Tagen ab“, wobei ein Archiv nur fünfmal heruntergeladen werden kann. Wer den Export am Freitagabend anstösst und dann in die Ferien fährt, fängt danach von vorne an.

Warum die Bilder nicht einfach hochgeladen werden

Neben jedem Bild liegt im Archiv eine JSON-Datei. Die Dokumentation von immich-go beschreibt, was dort steht: der ursprüngliche Dateiname, das Aufnahmedatum als Zahl in Sekunden, die GPS-Koordinaten, ob das Bild im Papierkorb lag und ob es aus einer Partnerfreigabe stammt. Alben sind im Archiv als eigene Ordner abgebildet. Vieles davon fehlt in den Bilddateien selbst, weil Google beim Export nicht alles zurückschreibt.

Dazu kommen die bekannten Eigenheiten des Exports, die das Projekt offen benennt: Bilder sind „duplicated with no apparent logic“ über mehrere Teilarchive verteilt, bearbeitete Fassungen haben manchmal keine JSON-Datei, und unbenannte Alben landen im selben Ordner — „Therefore it's impossible to rebuild original albums“. Ein Import, der das ignoriert, erzeugt Dubletten und Alben, die niemand wiedererkennt.

Das offizielle Kommandozeilenwerkzeug von Immich hilft hier nicht weiter, und das sagt es selbst: In der Dokumentation zur Immich-CLI steht „If you are looking to import your Google Photos takeout, we recommend this community maintained tool immich-go“. Die Bastellösung ist hier also der offiziell empfohlene Weg.

Schritt zwei: der Import mit immich-go

immich-go beschreibt sich als „An alternative to the immich-CLI command that doesn't depend on nodejs installation. It tries its best for importing google photos takeout archives.“ Es ist ein einzelnes übersetztes Programm, das ihr als fertige Datei für Linux, macOS, Windows und FreeBSD aus den Releases herunterladet — keine Abhängigkeiten, keine Installation.

Gebraucht wird ein API-Schlüssel aus der Weboberfläche, unter Account Settings > API Keys. Die Hinweise zur guten Praxis empfehlen einen eigenen Schlüssel mit nur den nötigen Rechten, und ihn nicht fest in ein Skript zu schreiben.

Erst ein Probelauf, der nichts schreibt:

./immich-go upload from-google-photos \
  --server=http://localhost:2283 \
  --api-key=EUER_API_SCHLUESSEL \
  --dry-run \
  /srv/takeout/takeout-*.zip

Sieht die Ausgabe plausibel aus, folgt der echte Durchlauf. Die Archive bleiben dabei gepackt, entpacken ist nicht nötig:

./immich-go upload from-google-photos \
  --server=http://localhost:2283 \
  --api-key=EUER_API_SCHLUESSEL \
  --manage-raw-jpeg=StackCoverRaw \
  --manage-burst=Stack \
  --pause-immich-jobs=true \
  /srv/takeout/takeout-*.zip

Die Optionen der Reihe nach: --manage-raw-jpeg=StackCoverRaw fasst RAW- und JPEG-Fassung derselben Aufnahme zu einem Stapel zusammen, statt zwei Einträge anzulegen. --manage-burst=Stack macht dasselbe mit Serienaufnahmen. --pause-immich-jobs=true hält die Hintergrundaufträge während des Imports an, was bei grossen Sammlungen empfohlen wird — der Server soll erst einlesen und danach analysieren.

Bricht der Vorgang ab, weil das Netz weg ist oder die Platte voll, startet ihr denselben Befehl einfach erneut: Laut Dokumentation erkennt das Werkzeug bereits vorhandene Dateien und überspringt sie. Einzelne Alben lassen sich mit --from-album-name="Ferien 2023" gezielt holen, und für Bilder, die nicht aus Google Fotos kommen, gibt es upload from-folder mit --folder-as-album=FOLDER.

Der erste Import einer grossen Mediathek braucht Stunden bis Tage. Lasst danach die Hintergrundaufträge durchlaufen, bevor ihr das Ergebnis beurteilt: Eine Zeitleiste mit halben Vorschaubildern ist kein Fehler, sondern eine Warteschlange.

Bestehende Ordner einbinden, statt sie zu kopieren

Wer seine Bilder schon sortiert auf einem NAS hat, will sie nicht ein zweites Mal hineinkopieren. Dafür gibt es externe Bibliotheken: Immich liest ein Verzeichnis, das ihr in den Container einbindet, und legt die Dateien nicht selbst an.

Der Zusatz in der Compose-Datei sieht so aus, und der Schalter am Ende ist der wichtige:

services:
  immich-server:
    volumes:
      - ${UPLOAD_LOCATION}:/data
      - /mnt/nas/fotoarchiv:/mnt/media/fotoarchiv:ro

Die Dokumentation erklärt dazu: „The ro flag at the end only gives read-only access to the volumes. This will disallow the images from being deleted in the web UI, or adding metadata to the library.“ Danach legt ihr unter Administration > External Libraries eine Bibliothek an und tragt als Importpfad den Pfad innerhalb des Containers ein, hier also /mnt/media/fotoarchiv. Importpfade werden rekursiv durchsucht, und mit Ausschlussmustern wie **/*.tif oder **/Raw/** lassen sich Dateitypen und ganze Unterordner auslassen.

Drei Eigenschaften solltet ihr kennen, bevor ihr das produktiv nutzt. Ein Suchlauf läuft standardmässig einmal täglich, der Zeitplan ist einstellbar. Verschwindet eine Datei auf der Platte, wandert der Eintrag beim nächsten Durchlauf in den Papierkorb von Immich und wird nach 30 Tagen endgültig entfernt. Und alles, was ihr in Immich an einem externen Bild ergänzt — Beschreibung, Schlagwörter, Personen —, bleibt in der Datenbank und wird nicht in die Datei zurückgeschrieben.

Von aussen erreichbar machen

Port 2283 direkt ins Internet zu stellen ist keine gute Idee, schon weil dann alles unverschlüsselt läuft. Der saubere Weg führt über einen Reverse Proxy mit eigenem Zertifikat; wie das mit Caddy in wenigen Zeilen gelingt, steht in unserer Anleitung zum Caddy Reverse Proxy mit automatischem HTTPS. Für Immich genügt dort ein Block dieser Art:

fotos.example.ch {
    reverse_proxy http://127.0.0.1:2283
    request_body {
        max_size 50GB
    }
}

Die Seite des Projekts zum Reverse Proxy nennt drei Punkte, an denen es sonst hakt. Erstens die Obergrenze für Uploads: Für nginx steht dort client_max_body_size 50000M, und wer sie zu klein setzt, bekommt genau bei den grossen Videos einen Fehler. Zweitens die Zeitgrenzen, die auf 600 Sekunden gehören — proxy_read_timeout 600s und Geschwister. Drittens die Weiterleitung für WebSockets über Upgrade und Connection "upgrade"; ohne sie lädt die Oberfläche, aktualisiert sich aber nie. Caddy bringt die WebSocket-Weiterleitung von sich aus mit, die Zeitgrenzen und die Uploadgrösse müsst ihr setzen.

Wer keinen öffentlichen Zugang braucht, nimmt stattdessen ein VPN und öffnet gar keinen Port — für einen Server, den nur die eigene Familie benutzt, die ruhigere Lösung.

Sichern: zwei Teile, zwei Verfahren

Immich trennt Daten und Metadaten, und genau so wird gesichert. Die Datenbank hält Pfade, Alben, Personen und Benutzer; die Dokumentation stellt klar: „Immich stores file paths and user metadata in the database. It does not scan the library folder, so database backups are essential.“ Ein Auszug entsteht so:

docker exec -t immich_postgres pg_dump --clean --if-exists \
  --dbname=immich --username=postgres | gzip > /srv/backup/immich-dump.sql.gz

Auf der Dateiseite sind laut Projekt UPLOAD_LOCATION/library, /upload und /profile die kritischen Verzeichnisse; empfohlen wird, UPLOAD_LOCATION vollständig zu sichern, „but only the original content is critical“. Vorschaubilder und umgewandelte Videos baut Immich bei Bedarf neu.

Zwei Regeln dazu. Erstens: Das Datenverzeichnis von Postgres wird nicht als Ordner kopiert. Ein solcher Abzug führt beim Zurückspielen zu Konflikten, und die Dokumentation beschreibt als Ausweg, DB_DATA_LOCATION zu löschen und die Datenbank neu aufzusetzen — was ohne gültigen Auszug bedeutet, dass alle Alben und Personen weg sind. Zweitens die Reihenfolge: Am besten wird der Container immich-server während der Sicherung angehalten. Ist das nicht möglich, sichert zuerst die Datenbank und danach die Dateien.

Beides lässt sich einrichten und dann vergessen. Wie ein solcher Auftrag mit einem systemd-Timer statt eines Cronjobs läuft und sich bei einem Fehlschlag von selbst meldet, haben wir separat beschrieben — gerade bei Sicherungen ist die Benachrichtigung bei Misserfolg der halbe Nutzen.

Aktualisieren, ohne Überraschungen

Ein Update besteht aus zwei Befehlen im Verzeichnis der Compose-Datei:

docker compose pull
docker compose up -d

Was dabei ankommt, entscheidet IMMICH_VERSION. Steht dort v3, holt ihr jeweils die neueste Fassung der Reihe. Vor jedem Sprung gehört ein Blick in die Veröffentlichungshinweise, und zwar aus einem konkreten Grund: Beim Sprung auf 3.0.0 waren die Änderungen mit Bruch überwiegend Schnittstellensachen, das Projekt schreibt dazu, „many of the breaking changes are updates to API endpoints and only affect third-party tools“. Für die Weboberfläche und die Apps war das unkritisch — für Skripte und Fremdwerkzeuge nicht.

Die Fassung 3.2.0 vom 10. September 2026 bringt unter anderem gemeinsame Personengruppen über Benutzergrenzen hinweg. Der Hinweis dazu ist unbedingt zu lesen, bevor die Funktion eingeschaltet wird: Sie verlangt ein Zurücksetzen der Gesichtserkennung für alle beteiligten Benutzer, und dabei gehen die vergebenen Namen und Geburtsdaten verloren. Eine Funktion, die Arbeit von Wochen löscht, gehört nicht in einen Feierabend-Klick.

Worauf ihr achten solltet

Die Fallen bei diesem Aufbau sind selten technisch schwierig, aber teuer, wenn sie erst nach dem Import auffallen:

• Registriert euch zuerst selbst. Das erste Konto wird Administrator. Der Port gehört erst danach nach draussen.
• Nur Buchstaben und Zahlen im Datenbankpasswort. Sonderzeichen in DB_PASSWORD führen zu einer Datenbank, die ohne verwertbare Meldung nicht startet.
• DB_DATA_LOCATION nicht auf eine Netzwerkfreigabe legen. Das ist ausdrücklich nicht unterstützt, und der Schaden zeigt sich erst unter Last.
• Das Speicher-Template vor dem ersten Import einschalten. Nachträglich geht es, verlangt aber einen Wartungsauftrag über den gesamten Bestand.
• Takeout-Archive niemals ohne Werkzeug hochladen. Ohne Auswertung der JSON-Dateien fehlen Datum, Ort und Alben — und das lässt sich später nur mit einem neuen Export nachholen.
• Platz für den Zuschlag einplanen. Vorschaubilder und umgewandelte Videos kommen mit 10 bis 20 Prozent obendrauf.
• Die Sicherung einmal zurückspielen. Ein Datenbankauszug, der noch nie eingelesen wurde, ist eine Vermutung.
• Externe Bibliotheken mit :ro einbinden. Ein Schreibzugriff auf das gewachsene Archiv ist ein Risiko, das keinen Vorteil bringt.

Erst ausprobieren, dann selbst aufsetzen

Bevor ihr eine Maschine aufsetzt, eine Platte einplant und einen Sicherungsauftrag schreibt, lässt sich die wichtigste Frage auch günstiger klären: Passt Immich überhaupt zu der Art, wie ihr eure Fotos verwaltet? Dafür betreiben wir unter unseren Free Services eine eigene Instanz, die ihr kostenlos nutzen könnt — immich.yourdevice.ch, mit 3 GB Speicher gratis für alle. Konto anlegen, App aufs Telefon, ein paar hundert Bilder hochladen.

Was ihr dort an einem Abend lernt, kann diese Anleitung nicht beantworten: ob euch die Zeitleiste liegt, ob die Suche nach Bildinhalten in eurer Sammlung tatsächlich trifft, ob die Gesichtserkennung eure Familie auseinanderhält und ob die App auf eurem Telefon zuverlässig sichert. Alles, was oben Platz braucht — Arbeitsspeicher, Speicherplatz, Reverse Proxy, Sicherung —, stellt sich dabei nicht, weil wir es übernehmen. Kein Tracking, keine Profilbildung, keine Weitergabe an Werbenetzwerke; der Dienst läuft nach denselben Regeln wie alles andere hier.

Und wenn ihr euch danach für den eigenen Server entscheidet, war die Testmediathek kein verlorener Aufwand: immich-go zieht nicht nur aus einem Google-Takeout um, sondern auch von einer Immich-Instanz zur nächsten. Die drei Gigabyte sind als Probe gedacht und nicht als Archiv — für fünfzehn Jahre Familienfotos braucht es die eigene Platte. Dafür steht der Rest dieser Anleitung.

Fazit: Immich ersetzt Google Fotos, aber kein Backup

Der Aufbau selbst ist erstaunlich unspektakulär: zwei heruntergeladene Dateien, fünf Zeilen Konfiguration, ein Befehl. Alles, was in dieser Anleitung Platz braucht, liegt davor und danach — die Frage, ob die Maschine reicht, die Entscheidung über das Speicher-Template, der Umzug der Google-Mediathek, die Sicherung. Wer diese vier Punkte vor dem ersten Bild klärt, hat einen Dienst, der jahrelang läuft. Wer sie überspringt, hat eine Zeitleiste voller Bilder mit Aufnahmedatum von letztem Dienstag.

Der wichtigste Satz steht dabei im Projekt selbst und nicht in dieser Anleitung: Die Datenbanksicherung deckt die Metadaten ab, für die Bilder und Videos seid ihr zuständig. Mit der Kontrolle über die eigenen Erinnerungen kommt die Verantwortung für die zweite Kopie — kein Nachteil des Selbsthostens, sondern dessen ehrlichere Variante. Bei Google lag die zweite Kopie auch nie bei euch, nur hat dort niemand darüber gesprochen.

Habt ihr Immich schon im Einsatz, oder einen Takeout-Import hinter euch, der anders verlief als beschrieben? Schreibt es in die Kommentare.

Quellen und weiterführende Links

• Immich: Requirements — Arbeitsspeicher, Kerne, x86-64-v2 ab Version 3, Dateisysteme und der Hinweis gegen Netzwerkfreigaben für die Datenbank
• Immich: Docker Compose Installation — die beiden Download-Adressen, die Variablen der .env und die Einschränkung beim Datenbankpasswort
• Immich: Quick Start — Port 2283, das erste Konto als Administrator und der Satz zur Eigenverantwortung bei der Sicherung der Dateien
• Immich: Post Installation — Speicher-Template, Bezugsquellen der mobilen Apps und der Verweis auf die 3-2-1-Strategie
• Immich: Backup and Restore — der pg_dump-Befehl im Wortlaut, die kritischen Unterverzeichnisse und die Warnung gegen das Kopieren des Postgres-Datenverzeichnisses
• Immich: Reverse Proxy — Uploadgrenze, Zeitgrenzen von 600 Sekunden und die Kopfzeilen für WebSockets
• Immich: External Libraries — Einbinden mit :ro, Importpfade, Ausschlussmuster, täglicher Suchlauf und Papierkorb nach 30 Tagen
• Immich: FAQ — Abschalten des maschinellen Lernens ganz oder je Modell, Zurücksetzen des Administratorpassworts
• Immich: Command Line Interface — Umfang der offiziellen CLI und die Empfehlung, für Google-Takeout immich-go zu nehmen
• immich-app/immich: docker/docker-compose.yml — die vier Dienste mit Abbildern, Volumes, Port und Abhängigkeiten
• Immich Blog: Release v3.0.0 — Erscheinungsdatum 1. Juli 2026 und die Einordnung der Änderungen mit Bruch
• immich-app/immich: Release v3.2.0 — Erscheinungsdatum 10. September 2026 und der Hinweis zum Zurücksetzen der Gesichtserkennung
• simulot/immich-go — Selbstbeschreibung des Werkzeugs, unterstützte Plattformen und der Hinweis, vorher eine Sicherung anzulegen
• immich-go: Google Takeout — Aufbau des Archivs, Inhalt der JSON-Dateien und die benannten Schwächen des Exports
• immich-go: Examples — die Befehle für from-google-photos und from-folder samt Optionen
• immich-go: Best Practices — API-Schlüssel, Probelauf, Anhalten der Hintergrundaufträge und Wiederaufnahme nach Abbruch
• Google: Daten herunterladen (Datenexport) — Auswahl einzelner Dienste, Dateityp und Archivgrösse, Ablauf nach etwa sieben Tagen und höchstens fünf Downloads

The post Immich selbst hosten: Google Fotos ersetzen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Vorausgesetzt wird, dass Flatpak eingerichtet ist und das Flathub-Repository eingebunden. Falls nicht: Der Weg dorthin steht bei uns im Beitrag darüber, wie ihr Snap vom System entfernt und durch Flatpak ersetzt. Wer bei den Paketformaten überhaupt noch schwankt, findet in der Übersicht zu Programminstallationen unter Linux die Einordnung.

Flatpak-Berechtigungen: was eine App ab Werk darf

Die offizielle Dokumentation ist an dieser Stelle erfreulich unmissverständlich. Eine Anwendung im Sandkasten hat laut Sandbox Permissions "extremely limited access to the host environment". Im Einzelnen heisst das: kein Zugriff auf Dateien des Wirtssystems ausser der Laufzeitumgebung, der App selbst, ~/.var/app/$FLATPAK_ID und $XDG_RUNTIME_DIR/app/$FLATPAK_ID. Kein Netzzugriff. Kein Zugriff auf Gerätedateien, abgesehen von /dev/null und ähnlichem. Kein Zugriff auf Prozesse ausserhalb des Sandkastens. Eingeschränkte Systemaufrufe, eingeschränkter Zugriff auf den Sitzungsbus von D-Bus. Und kein Zugriff auf Dienste des Wirtssystems wie X11, den Systembus oder PulseAudio.

Das ist eine Ausgangslage, mit der sich arbeiten lässt. Technisch steckt dahinter kein Flatpak-Eigenbau, sondern bubblewrap, ein Werkzeug, das unprivilegierten Nutzern erlaubt, Container aufzuspannen — mit Namensräumen, Bind-Mounts und Seccomp-Regeln, also mit Kernelmitteln, die es ohnehin gibt.

Der Haken liegt nicht im Sandkasten, sondern in der Liste der Ausnahmen. Jede App bringt im Manifest eine Reihe von Rechten mit, die sie beim Bauen angefordert hat, und die werden beim Start wortlos gewährt. Ein Bildbetrachter mit --filesystem=home sieht euer gesamtes Heimatverzeichnis, inklusive SSH-Schlüssel, Steuerunterlagen und der Wallet-Datei. Niemand fragt euch beim ersten Start, ob das in Ordnung ist. Genau hier setzen die Werkzeuge an, um die es im Folgenden geht.

Warum das mit chmod und chown nichts zu tun hat

Eine Verwechslung vorweg, weil sie die häufigste ist. Die klassischen Unix-Rechte regeln, wer auf eine Datei zugreifen darf — welcher Benutzer, welche Gruppe. Wie das funktioniert, haben wir im Beitrag zu Linux-Gruppen und Berechtigungen mit rwx, chmod und chown ausführlich behandelt. Diese Schicht sagt aber nichts darüber aus, was ein Programm tut, das ihr selbst gestartet habt. Für den Kernel seid ihr das, und ihr dürft eure eigenen Dateien lesen.

Die Sandbox ist die Schicht darüber. Sie schränkt ein, was ein Prozess mit euren Rechten tatsächlich erreichen kann. Ein verwandter Ansatz ist Mandatory Access Control, wie wir sie beim Absichern des Firefox mit AppArmor gezeigt haben — nur dass dort ein Profil von aussen aufgesetzt wird, während Flatpak den Sandkasten mitbringt und ihr nur die Türen darin verriegelt. Beides schliesst sich nicht aus, beides ersetzt sich aber auch nicht.

Die sechs Stellschrauben der Sandbox

Alles, was aus dem Sandkasten herausführt, fällt in eine von sechs Kategorien. Die Namen dieser Kategorien sind zugleich die Schalter, mit denen ihr sie bedient — auf der Kommandozeile wie in Flatseal.

Zu jedem dieser Schalter gibt es die Gegenform: --unshare, --nosocket, --nodevice, --nofilesystem, --no-talk-name und --disallow. Genau die braucht ihr, denn ihr wollt in aller Regel etwas wegnehmen, nicht dazugeben.

Drei Werte, die besondere Aufmerksamkeit verdienen

--filesystem=host bedeutet Zugriff auf alle obersten Pfade von / und deren Unterpfade, abgesehen von wenigen reservierten. --filesystem=home gewährt das Heimatverzeichnis mit Ausnahme von ~/.var/app. Beide lassen sich mit den Zusätzen :ro für nur lesend und :create für lesend und schreibend samt Anlegen des Verzeichnisses verfeinern. Die Dokumentation formuliert die Regel dazu selbst: "As a general rule, static and permanent filesystem access should be limited as much as possible."

--socket=session-bus und --socket=system-bus heben die Filterung des D-Bus vollständig auf. Die Dokumentation nennt das ausdrücklich ein Sicherheitsrisiko: "Access to the entire bus with --socket=system-bus or --socket=session-bus stops the filtering and using them is a security risk." Eine App mit vollem Sitzungsbus kann mit allem sprechen, was auf eurem Desktop lauscht — und das ist mehr, als die meisten vermuten.

--share=network ist nicht nur ein Netzzugang. Die Sandbox Permissions Reference weist darauf hin, dass damit auch der Zugriff auf alle Dienste des Wirtssystems freigeschaltet wird, die über abstrakte Unix-Sockets erreichbar sind — und die kennen keine Rechteprüfung. Betroffen sind unter anderem der X-Server und der Sitzungsbus. Ein Netzrecht ist also potenziell mehr als ein Netzrecht.

Erst nachsehen: welche Rechte hat die App wirklich?

Bevor ihr irgendetwas ändert, schaut ihr nach. Die Anwendungs-ID bekommt ihr aus der Liste der installierten Pakete:

flatpak list --app --columns=name,application,origin

Die zweite Spalte ist die Anwendungs-ID in der Form org.mozilla.firefox oder org.gimp.GIMP. Mit ihr fragt ihr die Rechte ab:

flatpak info --show-permissions org.mozilla.firefox

Die Kurzform ist -M. Die Ausgabe ist eine Abschnittsdatei im INI-Stil mit einer Gruppe [Context], in der die Schlüssel shared, sockets, devices, filesystems und features stehen, dazu je nach App eine Gruppe für die D-Bus-Regeln. Genau diese Schlüssel entsprechen den Schaltern aus der Tabelle oben.

Zwei weitere Abfragen sind im Alltag nützlich. Das vollständige Manifest mit allen Metadaten liefert:

flatpak info --show-metadata org.mozilla.firefox

Und wenn ihr wissen wollt, ob eine bestimmte App an einen bestimmten Pfad herankommt, fragt ihr das direkt ab, statt es zu raten:

flatpak info --file-access=$HOME/.ssh org.mozilla.firefox

Die Handbuchseite flatpak-info(1) beschreibt alle Optionen. Wichtig zu wissen: Sobald ihr eine --show-…-Option oder --file-access benutzt, wechselt die Ausgabe in ein maschinenlesbares Format. Das ist praktisch, wenn ihr die Abfrage in ein Skript giesst.

flatpak override: Rechte auf der Kommandozeile ändern

Das Werkzeug der Wahl ist flatpak-override(1). Die Handbuchseite beschreibt seinen Zweck knapp: "Overrides the application specified runtime requirements. This can be used to grant a sandboxed application more or less resources than it requested." Das Manifest der App bleibt dabei unangetastet — ihr legt eine zusätzliche Schicht darüber.

Benutzerweit oder systemweit

--user ändert eine Einstellung nur für euer Benutzerkonto, --system für die systemweite Installation. Für --system braucht ihr Administratorrechte. Im Zweifel nehmt ihr --user: Die Änderung gilt dort, wo ihr arbeitet, und ein zweites Konto auf demselben Rechner bleibt unberührt.

Ein Recht wegnehmen

Der häufigste Fall. Ihr entzieht einer App den Vollzugriff auf das Heimatverzeichnis:

flatpak override --user --nofilesystem=home org.mozilla.firefox

Ebenso lassen sich Netz, Geräte und Bus-Zugriffe entziehen:

flatpak override --user --unshare=network org.gimp.GIMP
flatpak override --user --nodevice=all org.gimp.GIMP
flatpak override --user --nosocket=session-bus org.gimp.GIMP

Die Handbuchseite beschreibt --nofilesystem genau so: "Undo the effect of a previous --filesystem=FILESYSTEM in the app's manifest or a lower-precedence layer of overrides." Damit ist auch gesagt, dass es mehrere Schichten gibt und dass eine spätere die frühere übersteuert.

Ein Recht gezielt wieder geben

Wenn ihr home weggenommen habt, die App aber einen bestimmten Ordner braucht, gebt ihr genau den zurück — und sonst nichts:

flatpak override --user --filesystem=~/Bilder:ro org.gimp.GIMP
flatpak override --user --filesystem=~/Projekte/grafik:create org.gimp.GIMP

:ro steht für nur lesend, :create für lesend und schreibend samt Anlegen des Verzeichnisses, falls es noch nicht existiert. Ohne Zusatz gilt lesend und schreibend auf ein bestehendes Verzeichnis.

Kontrollieren und zurücksetzen

Was ihr gesetzt habt, zeigt euch --show, und --reset räumt es wieder ab:

flatpak override --user --show org.gimp.GIMP
flatpak override --user --reset org.gimp.GIMP

Das ist die wichtigste Zeile dieses Artikels, denn sie nimmt jedem Experiment den Schrecken: Wer sich verrannt hat, setzt zurück und fängt von vorn an. Am Manifest der App ändert sich dabei nichts.

Globale Overrides für alle Anwendungen

Lasst ihr die Anwendungs-ID weg, gilt die Einstellung für alle Flatpaks. Die Handbuchseite sagt das zu --reset und --show ausdrücklich: ohne APP betreffen sie "the global overrides". Damit lässt sich eine Grundlinie ziehen:

flatpak override --user --nofilesystem=host
flatpak override --user --nosocket=x11

Achtung: Ein globales --nosocket=x11 legt auf einem X11-Desktop sämtliche grafischen Flatpak-Anwendungen still. Setzt das nur, wenn eure Sitzung tatsächlich auf Wayland läuft, und prüft das vorher mit echo $XDG_SESSION_TYPE. Ein globales Override, das alles kaputtmacht, fällt erst beim nächsten Programmstart auf — und dann sucht ihr an der falschen Stelle.

Wo die Overrides liegen und wer wen übersteuert

Overrides sind gewöhnliche Textdateien. Die Handbuchseite nennt für den Benutzermodus den Pfad $XDG_DATA_HOME/flatpak/overrides, auf einem Standardsystem also ~/.local/share/flatpak/overrides/. Je Anwendung liegt dort eine Datei, die genauso heisst wie die Anwendungs-ID; die globalen Einstellungen stehen in einer Datei namens global.

Das Format ist dasselbe wie bei flatpak info --show-metadata, also Abschnitte im INI-Stil mit einer Gruppe [Context]. Ihr könnt diese Dateien mit einem Editor öffnen, versionieren und auf einen anderen Rechner kopieren. Für ein neu aufgesetztes System ist das der schnellste Weg, die eigene Rechtelage wiederherzustellen — ein Ordner, ein cp, fertig.

Die Reihenfolge, in der die Schichten greifen, ist die logische: Zuunterst steht, was die App im Manifest angefordert hat. Darüber legen sich die systemweiten Overrides, darüber die benutzerweiten, und ganz oben stehen die Rechte, die ihr einer App für einen einzelnen Start mit flatpak run und denselben Schaltern mitgebt. Eine höhere Schicht kann eine tiefere sowohl erweitern als auch beschneiden.

Flatseal: dasselbe mit der Maus

Flatseal beschreibt sich selbst als "a graphical utility to review and modify permissions from your Flatpak applications". Es ist von Martin Abente Lahaye, steht unter der GPL Version 3 oder später und liegt auf Flathub unter der Anwendungs-ID com.github.tchx84.Flatseal, zum Zeitpunkt dieses Artikels in Version 2.4.1.

flatpak install flathub com.github.tchx84.Flatseal

Was Flatseal tut, ist genau das, was flatpak override tut — es schreibt dieselben Dateien an derselben Stelle. Der Unterschied ist die Übersicht: Links stehen alle installierten Anwendungen, rechts sämtliche Kategorien als Schalterreihe, und ein Schalter, den ihr umlegt, erscheint sofort als Eintrag in der Override-Datei. Das ist der eigentliche Wert des Werkzeugs: Ihr seht auf einen Blick, was eine App angefordert hat und was ihr davon geändert habt, ohne fünf Abfragen zu tippen.

Drei Punkte zur Bedienung, die im Alltag zählen. Erstens gelten Änderungen erst, wenn die betroffene Anwendung neu gestartet wird — eine laufende Instanz behält ihre Rechte bis zum Ende. Zweitens gibt es je Anwendung eine Schaltfläche zum Zurücksetzen, die dem --reset von oben entspricht. Drittens hat Flatseal einen Eintrag "Alle Anwendungen" ganz oben in der Liste; was ihr dort einstellt, landet in den globalen Overrides und gilt für jedes Flatpak auf dem System.

Wer lieber klickt als tippt, verliert dabei nichts — die erzeugten Dateien sind identisch. Wer beides kann, nimmt Flatseal zum Nachsehen und die Kommandozeile zum Wiederherstellen auf dem nächsten Rechner.

Portals: warum weniger Rechte nicht weniger Funktion heissen

Jetzt kommt der Teil, der den ganzen Aufwand erst sinnvoll macht. Wenn ihr einer Anwendung --filesystem=home entzieht, könnt ihr trotzdem weiterhin Dateien darin öffnen. Zuständig dafür sind die Portals.

Die Dokumentation von xdg-desktop-portal nennt den Zweck so: "The primary goal of portals is to expose common functionality and integration with the desktop without requiring apps to write desktop-specific code, or loosen their sandbox restrictions." Der zweite Halbsatz ist der entscheidende.

Praktisch funktioniert das über den Documents-Portal, dessen Dokumentation den Mechanismus beschreibt: "The document portal allows to make files from the outside world available to sandboxed applications in a controlled way." Wählt ihr im Dateidialog eine Datei aus, wird sie in den Dokumentenspeicher aufgenommen und der Anwendung unter /run/user/$UID/doc/$DOC_ID/dateiname zugänglich gemacht. Dort hängt ein FUSE-Dateisystem, das jeder Anwendung nur die Dateien zeigt, für die sie eine Freigabe hat; die erteilten Rechte — lesen, schreiben, weitergeben, löschen — bilden sich in den POSIX-Modusbits dieses Dateisystems ab.

Der Unterschied zum statischen Recht ist damit klar: Statt einer Pauschalerlaubnis für alles im Heimatverzeichnis bekommt die Anwendung eine Einzelfreigabe für genau die Datei, die ihr ausgewählt habt. Der Dateidialog, den ihr dabei seht, gehört nicht zur Anwendung, sondern zum Desktop. Die Anwendung erfährt erst danach, was ihr ausgesucht habt.

Diese dynamisch vergebenen Rechte landen im Permission Store, einer Datenbank, die von den Portals gepflegt wird. flatpak-permission-show(1) zeigt sie an:

flatpak permissions
flatpak permission-show org.gimp.GIMP
flatpak permission-reset org.gimp.GIMP

flatpak permissions listet den gesamten Bestand, permission-show die einer einzelnen Anwendung und permission-reset setzt sie zurück. Merkt euch die Trennung: override betrifft die statischen Rechte aus dem Manifest, permission-* die dynamischen aus den Portals. Beides sind Berechtigungen, beides sind verschiedene Speicher, und wer an der falschen Stelle sucht, findet nichts.

Drei Zuschnitte, die sich sofort lohnen

Der Bildbetrachter oder Medienspieler

Ein Programm, das lokale Dateien anzeigt, braucht weder Netz noch Sitzungsbus. Es braucht die Grafikausgabe und das Verzeichnis, in dem die Dateien liegen:

flatpak override --user --unshare=network org.videolan.VLC
flatpak override --user --nofilesystem=home org.videolan.VLC
flatpak override --user --filesystem=xdg-videos:ro org.videolan.VLC

Prüft danach mit flatpak info --show-permissions org.videolan.VLC und startet das Programm einmal. Braucht es Netz für Streams, nehmt ihr die erste Zeile mit --reset zurück oder setzt sie mit --share=network wieder.

Die Bildbearbeitung

Bei einem Programm, das Dateien öffnet und speichert, ist der Dateidialog über das Portal die richtige Antwort. Ihr nehmt den Vollzugriff weg und gebt nur den Arbeitsordner zurück:

flatpak override --user --nofilesystem=home org.gimp.GIMP
flatpak override --user --filesystem=~/Projekte:create org.gimp.GIMP
flatpak override --user --unshare=network org.gimp.GIMP

Der Browser

Ein Browser braucht Netz, das steht ausser Frage. Was er nicht braucht, ist Lesezugriff auf alles, was in eurem Heimatverzeichnis liegt. Für Downloads und Uploads reicht ein Verzeichnis, alles Weitere geht über den Dateidialog:

flatpak override --user --nofilesystem=home org.mozilla.firefox
flatpak override --user --filesystem=xdg-download org.mozilla.firefox

Falls die Anwendung danach Zugangsdaten nicht mehr im Schlüsselbund ablegen kann, fehlt ihr die D-Bus-Gegenstelle dafür. Die gebt ihr gezielt zurück, statt den ganzen Bus zu öffnen:

flatpak override --user --talk-name=org.freedesktop.secrets org.mozilla.firefox

Was die Sandbox nicht leistet

Ein paar ehrliche Einschränkungen gehören dazu, sonst wird aus einer Schutzschicht ein Sicherheitsversprechen, das sie nicht halten kann.

Erstens bleibt alles bestehen, was über die Portals hereinkommt. Eine Anwendung, der ihr im Dateidialog eure Steuererklärung gebt, hat die Steuererklärung. Der Sandkasten schützt vor dem pauschalen Zugriff, nicht vor eurer eigenen Auswahl.

Zweitens ist ein Recht, das ihr entzieht, nur so wirksam wie die Alternative, die bleibt. Nehmt ihr einer Anwendung home weg und gebt ihr stattdessen --filesystem=host:ro, habt ihr nichts gewonnen, sondern die Lage verschlimmert. Ein Blick in die Ausgabe von --show-permissions nach jeder Änderung erspart solche Eigentore.

Drittens lebt die Paketbasis von Flathub von den Paketbauern, und die entscheiden, welche Rechte eine App ab Werk anfordert. Die Sandbox ist eine Grenze, keine Prüfinstanz. Sie sagt euch nicht, ob ein Paket vertrauenswürdig ist — sie begrenzt nur den Schaden, wenn es das nicht ist. Das ist kein kleiner Unterschied, aber eben auch nicht derselbe.

Viertens gilt alles Gesagte nur für Flatpak. Ein Programm aus dem Paketmanager der Distribution läuft ohne Sandkasten, und ein AppImage ebenso. Wer eine Anwendung wirklich einsperren will, für die es kein Flatpak gibt, landet wieder bei AppArmor oder einem der klassischen Werkzeuge.

Wenn etwas nicht klappt

Die Anwendung startet nicht mehr. Setzt die Overrides für genau diese Anwendung zurück und nähert euch in kleineren Schritten: flatpak override --user --reset org.beispiel.App. Startet sie danach wieder, lag es an einer eurer Änderungen.

Gar keine grafische Anwendung startet mehr. Dann steht die Ursache mit hoher Wahrscheinlichkeit in den globalen Overrides. Ansehen und zurücksetzen lassen sie sich ohne Anwendungs-ID: flatpak override --user --show und flatpak override --user --reset. Typischer Auslöser ist ein entzogener x11- oder wayland-Socket.

Die Änderung wirkt nicht. Prüft dreierlei: ob die Anwendung neu gestartet wurde, ob ihr --user gesetzt habt, während die App systemweit installiert ist (oder umgekehrt), und ob eine andere Schicht euer Override übersteuert. flatpak info --show-permissions zeigt den tatsächlich wirksamen Stand, flatpak override --show nur eure eigene Schicht. Weichen beide voneinander ab, habt ihr die Antwort.

Der Dateidialog zeigt nichts an oder es öffnet sich keiner. Dann fehlt auf dem System das passende Portal-Backend. Gebraucht werden xdg-desktop-portal und je nach Desktop xdg-desktop-portal-gtk, -kde oder -wlr. Auf schlanken Fenstermanager-Installationen fehlt das oft, und dann scheitert jede Anwendung ohne statisches Dateirecht.

Eine Funktion fehlt, und ihr wisst nicht, welches Recht dahintersteckt. Für D-Bus gibt es dafür ein eigenes Mittel. Die Dokumentation nennt es ausdrücklich: flatpak run --log-session-bus $FLATPAK_ID protokolliert, mit welchen Busnamen die Anwendung sprechen will. Aus dieser Liste ergibt sich, welches --talk-name ihr setzen müsst.

Ihr habt den Überblick verloren, was ihr überhaupt geändert habt. Der Ordner ~/.local/share/flatpak/overrides/ beantwortet das in einem Rutsch. Was dort nicht steht, habt ihr auch nicht gesetzt.

Fazit: Die Sandbox ist nur so eng, wie ihr sie einstellt

Flatpak liefert einen Sandkasten, der in der Voreinstellung tatsächlich streng ist — und ein Manifest, das diese Strenge gleich wieder aufweicht, ohne euch zu fragen. Beides zusammen ergibt ein System, das genau so sicher ist, wie jemand es nachträglich einstellt. Der Aufwand dafür ist überschaubar: eine Abfrage, ein bis zwei Overrides, ein Neustart der Anwendung.

Der wichtigste Schritt ist der erste. Lasst einmal flatpak info --show-permissions über eure installierten Anwendungen laufen und schaut, wer alles home oder host in der Liste stehen hat. Erfahrungsgemäss sind es mehr, als angenehm ist. Alles danach ist Handwerk, und das steht oben.

Und die Portals nehmen dem Ganzen die Härte: Weniger statische Rechte heissen nicht weniger Funktion, sondern nur, dass die Anwendung beim Zugriff durch eine Tür geht, die ihr aufhaltet. Das ist die Art von Sicherheit, die im Alltag überlebt — anders als die, bei der nach zwei Wochen alles wieder aufgedreht wird, weil nichts mehr ging.

Quellen und weiterführende Links

• Flatpak-Dokumentation: Sandbox Permissions — Voreinstellungen des Sandkastens, Dateisystem-, D-Bus- und Geräterechte
• Flatpak-Dokumentation: Sandbox Permissions Reference — Einzelwerte mit Erklärung und Sicherheitshinweisen
• Flatpak-Dokumentation: Under the Hood — bubblewrap, Namensräume und Seccomp
• Flatpak-Dokumentation: Desktop Integration — Portals als Rahmen für den Zugriff nach aussen
• Handbuchseite flatpak-override(1) — sämtliche Schalter im Wortlaut
• Handbuchseite flatpak-info(1) — --show-permissions, --show-metadata, --file-access
• Handbuchseite flatpak(1) — Übersicht aller Unterbefehle
• Handbuchseite flatpak-permission-show(1) — der Permission Store der Portals
• XDG Desktop Portal: For App Developers — Zweck und Aufbau der Portals
• XDG Desktop Portal: Documents — Dokumentenspeicher, FUSE-Einhängepunkt und Rechtebits
• Flatseal auf Flathub — Beschreibung, Version und Installationsweg
• Flatseal: Quelltext und README — Lizenz und Projektbeschreibung
• Linux: wichtige Begriffe in der Übersicht — Einordnung von Flatpak und Snap für Einsteiger

The post Flatpak-Berechtigungen einschränken: Flatseal und Terminal appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Diese Anleitung setzt voraus, dass ihr euch schon einmal per Schlüsselpaar bei einem Server angemeldet habt. Darauf baut alles auf, was hier folgt — ein Zertifikat ersetzt das Schlüsselpaar nicht, es kommt oben drauf. Wir richten eine eigene Zertifizierungsstelle ein, signieren damit Benutzer- und Hostschlüssel, begrenzen deren Rechte und Laufzeit und widerrufen sie am Ende wieder. Alles mit Bordmitteln von OpenSSH, ohne Zusatzsoftware und ohne fremden Dienst.

Warum SSH-Zertifikate das Problem mit authorized_keys lösen

Die klassische Anmeldung per öffentlichem Schlüssel ist eine Liste. Auf jedem Server steht in ~/.ssh/authorized_keys, welche Schlüssel dort hineindürfen. Ab dem dritten Server wird daraus eine Matrix: Jeder Schlüssel muss auf jeden Server, jede Änderung überall nachgezogen werden.

Das eigentliche Problem ist aber nicht das Hinzufügen, sondern das Wegnehmen. Ein einmal verteilter Schlüssel bleibt gültig, bis ihn jemand aktiv entfernt — auf jedem einzelnen Server. Verschwindet ein Notebook, beginnt eine Suchaktion durch Rechner, die vielleicht gerade gar nicht laufen. Ein öffentlicher Schlüssel hat kein Ablaufdatum, keinen Besitzer und keine Rolle. Er ist einfach da.

Ein Zertifikat dreht das um. Dem Server wird einmalig gesagt, welcher Zertifizierungsstelle er glaubt. Danach zählt kein einzelner Schlüssel mehr, sondern nur noch: Ist dieses Zertifikat von der richtigen Stelle unterschrieben, ist es noch gültig, und steht darin ein Name, der hier etwas zu suchen hat? Wer geht, bekommt kein neues mehr — und das alte läuft von allein ab.

Was ein Zertifikat ist — und was es ausdrücklich nicht ist

Das Verfahren ist keine Neuerung. OpenSSH hat es mit Version 5.4 am 8. März 2010 eingeführt: "Add support for certificate authentication of users and hosts using a new, minimal OpenSSH certificate format (not X.509)." Es steckt also seit über fünfzehn Jahren in jedem halbwegs gepflegten System.

Der Klammerzusatz ist wichtig. Ein SSH-Zertifikat hat mit den X.509-Zertifikaten, die euer Browser für HTTPS auswertet, nichts zu tun — kein gemeinsames Format, keine gemeinsame Werkzeugkette, keine Wurzelzertifikate von Dritten. Die Entwickler begründen das in der Formatbeschreibung PROTOCOL.certkeys so: "SSH eschews the use of X.509 certificates and uses raw keys. This approach has some benefits relating to simplicity of configuration and minimisation of attack surface." Weniger Angriffsfläche durch weniger Format — eine Begründung, die in dieser Branche selten zu lesen ist.

Was drinsteht, beschreibt die Handbuchseite ssh-keygen(1) knapp: "Certificates consist of a public key, some identity information, zero or more principal (user or host) names and a set of options that are signed by a Certification Authority (CA) key." Es gibt zwei Sorten: Ein Benutzerzertifikat weist einen Benutzer gegenüber einem Server aus, ein Hostzertifikat den Server gegenüber dem Benutzer. Beide entstehen mit demselben Werkzeug und sind unabhängig voneinander nutzbar.

Principals: der Name, auf den es ankommt

Der wichtigste Teil eines Zertifikats sind die Principals. Bei einem Benutzerzertifikat sind das Namen, unter denen sich der Inhaber anmelden darf. Bei einem Hostzertifikat sind es Rechnernamen; laut ssh-keygen(1) gilt dort: "For host certificates, principals are hostnames and may include wildcards."

Ein Principal ist nicht zwingend ein Unix-Benutzername. Er kann eine Rolle sein — deploy, dba, backup —, und der Server entscheidet getrennt davon, welche Rolle sich als welcher Benutzer anmelden darf. Darauf kommen wir in Schritt 4 zurück.

Critical Options und Extensions

In einem Zertifikat stehen ausserdem Einschränkungen und Erlaubnisse, und die sind in zwei Töpfe geteilt. PROTOCOL.certkeys erklärt den Unterschied: "critical options are used to control features that restrict access where extensions are used to enable features that grant access. This ensures that certificates containing unknown restrictions do not inadvertently grant access while allowing new protocol features to be enabled via extensions without breaking certificates' backwards compatibility."

Praktisch heisst das: Eine critical option, die ein alter Server nicht kennt, lässt ihn das Zertifikat ablehnen. Eine unbekannte extension ignoriert er. Einschränkungen fallen im Zweifel zu eurem Vorteil aus, Erlaubnisse im Zweifel weg — genau so herum soll es sein.

Was ihr für diese Anleitung braucht

• Mindestens einen Linux-Server mit OpenSSH-Server und funktionierendem Schlüssel-Login, dazu einen Arbeitsrechner mit OpenSSH-Client.
• Einen dritten, möglichst gut abgesicherten Ort für den CA-Schlüssel. Ein verschlüsselter USB-Stick genügt, ein zweiter Rechner ist besser.
• Einen zweiten Zugangsweg zum Server für den Notfall: eine offene zweite SSH-Sitzung, eine Konsole beim Anbieter oder physischen Zugriff.

Die Befehle sind für Debian und Ubuntu geschrieben und laufen auf anderen Distributionen genauso; nur Pfade und Paketnamen können abweichen.

Schritt 1: Die CA erzeugen und sofort wegsperren

Eine Zertifizierungsstelle ist bei OpenSSH nichts anderes als ein normales Schlüsselpaar — kein eigenes Format, kein Dienst, keine Datenbank. Erzeugt wird sie auf dem Rechner, auf dem sie später bleiben soll, nicht auf dem Server, den ihr damit absichern wollt:

mkdir -p ~/ssh-ca && chmod 700 ~/ssh-ca
cd ~/ssh-ca
ssh-keygen -t ed25519 -f user_ca -C "user-ca yourdevice"
ssh-keygen -t ed25519 -f host_ca -C "host-ca yourdevice"

Zwei getrennte Schlüssel, einer für Benutzer- und einer für Hostzertifikate. Technisch ginge auch einer. Tut es nicht: Wenn ihr den Host-Schlüssel später auf ein Provisionierungssystem legt, soll damit nicht zugleich der Benutzerzugang unterschrieben werden können.

Vergebt für beide Schlüssel eine Passphrase. Das ist hier keine Geschmacksfrage wie beim Anmeldeschlüssel. Wer diese Datei ohne Passphrase in die Hände bekommt, kann sich selbst ein gültiges Zertifikat für jeden eurer Server ausstellen, und ihr merkt es nicht. Prüft anschliessend die Rechte — die privaten Dateien gehören ausschliesslich euch, wie in unserem Beitrag zu Gruppen und Berechtigungen unter Linux beschrieben:

chmod 600 ~/ssh-ca/user_ca ~/ssh-ca/host_ca
chmod 644 ~/ssh-ca/user_ca.pub ~/ssh-ca/host_ca.pub
ls -l ~/ssh-ca

Legt jetzt eine Sicherung der beiden privaten Schlüssel an einem zweiten Ort an. Ein verlorener CA-Schlüssel bedeutet, dass ihr auf jedem Server von Hand wieder auf authorized_keys zurückfallen müsst. Wer ohnehin mit Hardwareschlüsseln arbeitet, findet die Grundlagen dazu unter Server SSH Zugang mit YubiKey absichern.

Schritt 2: Den Servern beibringen, wem sie glauben

Kopiert den öffentlichen Teil der Benutzer-CA auf den Server. Nur diesen — der private Schlüssel hat auf dem Server nichts verloren:

scp ~/ssh-ca/user_ca.pub benutzer@server:/tmp/user_ca.pub
ssh benutzer@server
sudo mv /tmp/user_ca.pub /etc/ssh/user_ca.pub
sudo chown root:root /etc/ssh/user_ca.pub
sudo chmod 644 /etc/ssh/user_ca.pub

Dann eine Zeile in die Serverkonfiguration. Die Direktive dafür heisst TrustedUserCAKeys und ist in sshd_config(5) beschrieben als "a file containing public keys of certificate authorities that are trusted to sign user certificates for authentication":

sudo tee /etc/ssh/sshd_config.d/60-ssh-ca.conf >/dev/null <<'EOF'
TrustedUserCAKeys /etc/ssh/user_ca.pub
EOF

sudo sshd -t && sudo systemctl reload ssh

Der Aufruf sshd -t prüft die Konfiguration, ohne den Dienst anzufassen. Nehmt ihn euch zur Gewohnheit: Ein Tippfehler in sshd_config und ein beherzter Neustart sind die klassische Art, sich selbst auszusperren. Heisst die Unit auf eurem System sshd statt ssh, passt den Namen an. Existiert /etc/ssh/sshd_config.d/ nicht oder wird es nicht eingebunden, schreibt die Zeile direkt in /etc/ssh/sshd_config.

Wichtig: Diese Zeile ergänzt die Anmeldung, sie ersetzt sie nicht. Eure bestehenden Einträge in authorized_keys funktionieren unverändert weiter — und das soll bis zum Schluss dieser Anleitung auch so bleiben.

Schritt 3: Den ersten Benutzerschlüssel signieren

Zurück auf dem Rechner mit der CA. Ihr braucht dort den öffentlichen Schlüssel des Anwenders, den ihr ausstatten wollt — also die Datei id_ed25519.pub von seinem Arbeitsgerät. Signiert wird so:

ssh-keygen -s ~/ssh-ca/user_ca \
  -I "mario@laptop" \
  -n mario,deploy \
  -V +8w \
  -z 1001 \
  id_ed25519.pub

Die Schalter stehen in ssh-keygen(1). -s gibt den CA-Schlüssel an, mit dem unterschrieben wird. -I setzt die Kennung, die später in jeder Protokollzeile des Servers auftaucht — nehmt etwas, mit dem ihr Person und Gerät wiederfindet. -n nennt die Principals: "Multiple principals may be specified, separated by commas." -V ist die Gültigkeit, -z eine Seriennummer, die laut Handbuch dazu dient, "to distinguish this certificate from others from the same CA" — die braucht ihr spätestens beim Widerrufen.

Herausgekommen ist eine Datei id_ed25519-cert.pub. Schaut sie euch an, bevor ihr sie weitergebt:

ssh-keygen -L -f id_ed25519-cert.pub

Die Ausgabe zeigt Typ, Kennung, Seriennummer, Principals, Gültigkeitszeitraum und die enthaltenen Erweiterungen im Klartext — eure Kontrolle, dass wirklich das im Zertifikat steht, was ihr gemeint habt.

Die Zertifikatsdatei kommt nun neben den privaten Schlüssel auf dem Arbeitsgerät, also nach ~/.ssh/id_ed25519-cert.pub. Mehr ist nicht zu tun: Laut ssh_config(5) gilt, dass "if no certificates have explicitly been specified by CertificateFile, ssh(1) will try to load certificate information from the filename obtained by appending -cert.pub to the path of a specified IdentityFile." Wollt ihr das Zertifikat woanders ablegen, tragt den Pfad mit CertificateFile in ~/.ssh/config ein.

Der Test:

ssh -v mario@server 2>&1 | grep -i cert

Taucht dort eine Zeile mit ED25519-CERT auf und die Anmeldung gelingt, ist der Weg fertig. Behaltet die alte Sitzung offen, bis das sicher funktioniert.

Schritt 4: Principals sauber von Benutzernamen trennen

Bis hierher hat der Server eine stillschweigende Annahme gemacht. sshd_config(5) beschreibt sie bei AuthorizedPrincipalsFile: Der Standardwert ist "none, i.e. not to use a principals file", und dann gilt — "in this case, the username of the user must appear in a certificate's principals list for it to be accepted". Deshalb steht oben mario in der Principal-Liste.

Das skaliert schlecht: Ihr müsstet in jedes Zertifikat jeden Benutzernamen schreiben, unter dem sich jemand irgendwo anmelden können soll. Der bessere Weg ist eine Datei je Zielbenutzer, die sagt, welche Rollen dort hineindürfen:

sudo mkdir -p /etc/ssh/auth_principals
echo 'deploy' | sudo tee /etc/ssh/auth_principals/www-deploy
echo -e 'dba\nnotfall' | sudo tee /etc/ssh/auth_principals/postgres
sudo chown -R root:root /etc/ssh/auth_principals
sudo chmod 644 /etc/ssh/auth_principals/*

Und in der Serverkonfiguration:

AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

Das %u ist der Benutzername, unter dem die Anmeldung versucht wird. Laut sshd_config(5) sind an dieser Stelle die Token %%, %h, %U und %u erlaubt. Wer sich als www-deploy anmelden will, braucht ab jetzt ein Zertifikat mit dem Principal deploy — sein eigener Benutzername steht nirgends mehr im Zertifikat.

Das ist der eigentliche Gewinn der ganzen Übung. Ihr stellt ein Zertifikat auf eine Rolle aus und entscheidet danach auf jedem Server lokal, welche Rolle dort etwas darf. Wer die Rolle verliert, verliert sie überall gleichzeitig — ohne dass ihr einen einzigen Schlüssel suchen müsst. Wird die Zuordnung komplizierter, gibt es dafür noch AuthorizedPrincipalsCommand, ein Programm, das die erlaubten Principals zur Laufzeit ausrechnet.

Schritt 5: Kurze Gültigkeit statt langer Schlüssel

Ein Zertifikat läuft ab, ein öffentlicher Schlüssel nicht. Das ist der zweite grosse Unterschied, und er ist mehr wert als jede Widerrufsliste. Die Syntax von -V beschreibt ssh-keygen(1) so: "A validity interval may consist of a single time, indicating that the certificate is valid beginning now and expiring at that time, or may consist of two times separated by a colon to indicate an explicit time interval." Die Beispiele aus dem Handbuch:

• +52w1d — gültig ab jetzt für 52 Wochen und einen Tag.
• -4w:+4w — gültig von vor vier Wochen bis in vier Wochen.
• 20100101123000:20110101123000 — ein fester Zeitraum mit Datum und Uhrzeit.
• -1m:forever — gültig ab vor einer Minute und niemals ablaufend.

Die letzte Form solltet ihr nicht benutzen. Sie baut genau den Zustand nach, den ihr gerade loswerden wolltet. Für Personen sind wenige Wochen ein brauchbarer Wert, für automatische Zugänge wie ein Deployment-Konto eher Stunden. Das kleine Minus am Anfang, etwa -5m:+8w, ist kein Schönheitsfehler, sondern der Umgang mit ungenauen Uhren: Läuft die Uhr des Servers ein paar Minuten vor, wäre ein frisch ausgestelltes Zertifikat dort sonst noch nicht gültig.

Kurze Laufzeiten heissen regelmässiges Nachsignieren. Ein kleines Skript, das den öffentlichen Schlüssel neu signiert und die Zertifikatsdatei ablegt, lässt sich sauber über einen systemd-Timer statt eines Cronjobs auslösen — samt Benachrichtigung, wenn es einmal nicht klappt. Achtet dabei darauf, dass der CA-Schlüssel dafür nicht ungeschützt auf einem dauerhaft laufenden Rechner landet.

Schritt 6: Was das Zertifikat überhaupt erlauben darf

Ohne weitere Angaben stellt ssh-keygen ein Zertifikat mit den üblichen Erlaubnissen aus: Terminal, Portweiterleitung, Agent-Weiterleitung, X11 und ~/.ssh/rc. Für ein Zertifikat, das nur ein Backup abholen soll, ist das zu viel. Mit -O clear räumt ihr erst alles ab — laut Handbuch "Clear all enabled permissions. This is useful for clearing the default set of permissions so permissions may be added individually." — und gebt danach einzeln zurück, was gebraucht wird:

ssh-keygen -s ~/ssh-ca/user_ca \
  -I "backup-runner" \
  -n backup \
  -V +1d \
  -z 2001 \
  -O clear \
  -O force-command="/usr/local/bin/backup-pull" \
  -O source-address=10.0.0.0/24 \
  backup_key.pub

Dieses Zertifikat kann genau eine Sache. force-command ist in PROTOCOL.certkeys beschrieben als "a command that is executed (replacing any the user specified on the ssh command-line) whenever this key is used for authentication" — was der Aufrufer als Befehl mitschickt, ist damit egal. source-address ist eine "comma-separated list of source addresses from which this certificate is accepted for authentication. Addresses are specified in CIDR format". Und weil permit-pty nach dem clear fehlt, gibt es kein Terminal: "In the absence of this option PTY allocation will be disabled."

Beide Beschränkungen sind critical options: Ein Server, der sie nicht versteht, lehnt das Zertifikat ab, statt es durchzuwinken. Die Erlaubnisse permit-pty, permit-port-forwarding, permit-agent-forwarding, permit-user-rc und permit-X11-forwarding sind dagegen extensions und werden stillschweigend übergangen, wenn ein Server sie nicht kennt.

Schritt 7: Hostzertifikate und das Ende der known_hosts-Frage

Bis jetzt ging es darum, wie der Server euch erkennt. Die andere Richtung ist mindestens so wichtig und wird viel seltener gemacht. Jeder kennt die Frage beim ersten Verbindungsaufbau, ob der Fingerabdruck des Servers stimmt — und jeder kennt die ehrliche Antwort darauf: Nachgeprüft wird sie fast nie, bestätigt wird sie immer.

Ein Hostzertifikat schafft diese Frage ab. Signiert wird der öffentliche Hostschlüssel des Servers, den ihr euch vorher holt:

scp benutzer@server:/etc/ssh/ssh_host_ed25519_key.pub .

ssh-keygen -s ~/ssh-ca/host_ca \
  -I "web01" \
  -h \
  -n web01.example.ch,web01,10.0.0.11 \
  -V +52w \
  -z 3001 \
  ssh_host_ed25519_key.pub

Der Schalter -h ist der Unterschied: "When signing a key, create a host certificate instead of a user certificate." In die Principals gehört jeder Name, unter dem der Server angesprochen wird — voller Name, Kurzform und IP-Adresse. Wer das vergisst, wundert sich, warum die Verbindung über die IP wieder nachfragt.

Die entstandene Datei ssh_host_ed25519_key-cert.pub kommt zurück auf den Server, und dort wird sie bekannt gemacht. sshd_config(5) beschreibt HostCertificate als "a file containing a public host certificate. The certificate's public key must match a private host key already specified by HostKey.":

scp ssh_host_ed25519_key-cert.pub benutzer@server:/tmp/
ssh benutzer@server
sudo mv /tmp/ssh_host_ed25519_key-cert.pub /etc/ssh/
sudo chown root:root /etc/ssh/ssh_host_ed25519_key-cert.pub
sudo chmod 644 /etc/ssh/ssh_host_ed25519_key-cert.pub
echo 'HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub' \
  | sudo tee -a /etc/ssh/sshd_config.d/60-ssh-ca.conf
sudo sshd -t && sudo systemctl reload ssh

Bleibt die Client-Seite. Der öffentliche Host-CA-Schlüssel kommt in die known_hosts, aber mit einem Marker davor. sshd(8) beschreibt ihn im Abschnitt zum Dateiformat: @cert-authority dient dazu, "to indicate that the line contains a certification authority (CA) key".

{ printf '@cert-authority *.example.ch '; cat ~/ssh-ca/host_ca.pub; } \
  >> ~/.ssh/known_hosts

Ab jetzt gilt jeder Server unter *.example.ch als bekannt, sobald er ein gültiges Hostzertifikat vorzeigt — auch der, den ihr erst nächste Woche aufsetzt. Löscht die alten Einzeleinträge dieser Server aus der Datei, sonst prüft der Client weiterhin gegen den dort hinterlegten Schlüssel. Auf mehreren Geräten genügt es, diese eine Zeile zu verteilen oder sie systemweit in /etc/ssh/ssh_known_hosts abzulegen.

Schritt 8: Widerrufen, bevor ihr es braucht

Kurze Laufzeiten sind die beste Widerrufsliste, weil sie ohne Zutun wirken. Trotzdem braucht ihr einen Weg, ein noch gültiges Zertifikat sofort zu entwerten. OpenSSH kennt dafür Key Revocation Lists, und ssh-keygen(1) beschreibt sie so: "These binary files specify keys or certificates to be revoked using a compact format." Erzeugt wird eine solche Liste mit -k:

ssh-keygen -k -f revoked.krl id_ed25519-cert.pub
ssh-keygen -k -u -f revoked.krl weiteres-cert.pub
ssh-keygen -Q -f revoked.krl id_ed25519-cert.pub

Die erste Zeile legt die Liste an, die zweite ergänzt sie — zu -u sagt das Handbuch: "keys listed via the command line are added to the existing KRL rather than a new KRL being created". Die dritte prüft nach: -Q "will query an existing KRL, testing each key specified on the command line" und endet mit einem Rückgabewert ungleich null, wenn der Schlüssel gesperrt ist. Sperren geht auch ohne das Zertifikat in der Hand, nämlich über Kennung oder Seriennummer — beim Erzeugen einer KRL gibt -s dann "a path to a CA public key file used to revoke certificates directly by key ID or serial number" an.

Die Liste muss auf jeden Server und dort eingetragen werden. RevokedKeys nimmt beide Formate: "Keys may be specified as a text file, listing one public key per line, or as an OpenSSH Key Revocation List (KRL) as generated by ssh-keygen(1)."

echo 'RevokedKeys /etc/ssh/revoked.krl' \
  | sudo tee -a /etc/ssh/sshd_config.d/60-ssh-ca.conf
sudo sshd -t && sudo systemctl reload ssh

Zwei Stolperfallen. Erstens: Zeigt RevokedKeys auf eine Datei, die es nicht gibt, verweigert sshd die Anmeldung — legt die Datei also an, bevor ihr die Zeile setzt. Zweitens wirkt eine Widerrufsliste nur dort, wo sie liegt; der beim Verteilen vergessene Server akzeptiert das gesperrte Zertifikat weiter. Für die Gegenrichtung kennt die known_hosts den Marker @revoked, der laut sshd(8) anzeigt, "that the key contained on the line is revoked and must not ever be accepted".

Der Preis: was ihr euch mit einer CA einhandelt

Ihr tauscht ein verteiltes Problem gegen ein zentrales ein, und diese Gegenseite ist nicht klein. Der CA-Schlüssel ist ab sofort der wertvollste Gegenstand in eurer Infrastruktur: Wer ihn hat, hat alles — ohne dass irgendwo eine Datei verändert werden müsste, die euch auffiele. Bei authorized_keys hinterlässt ein Angreifer wenigstens Spuren.

Dazu kommen praktische Kanten. Zertifikate laufen ab, und sie tun das mit Vorliebe am Freitagabend. Verwaltungsoberflächen von Anbietern, Netzwerkgeräte und manche Backup-Ziele sprechen nur klassische Schlüssel; ihr braucht also weiterhin einen Rückfallweg, der ebenso gepflegt werden will. Und der ganze Aufbau hängt an synchronen Uhren.

Unterhalb von etwa drei Servern und zwei Geräten lohnt sich das schlicht nicht. Wer einen Heimserver betreibt, ist mit einem sauber gesetzten Schlüssel, abgeschalteter Passwortanmeldung und einer Absicherung wie CrowdSec besser bedient als mit einer eigenen Zertifizierungsstelle. Interessant wird es ab dem Punkt, an dem ihr anfangt, eine Tabelle darüber zu führen, welcher Schlüssel auf welchem Rechner liegt.

Bevor ihr die CA scharf schaltet

Diese Anleitung hat bewusst nichts abgeschaltet. Der letzte Schritt — authorized_keys leeren — kommt erst, wenn diese Punkte alle abgehakt sind:

• Eine zweite SSH-Sitzung zum Server ist offen und bleibt offen, bis alles geprüft ist. Sie ist eure Rückfahrkarte.
• Die Anmeldung mit Zertifikat funktioniert aus einer neuen Sitzung, nicht nur laut ssh -v.
• Der private CA-Schlüssel liegt gesichert an einem zweiten Ort, ist mit einer Passphrase geschützt und befindet sich nicht auf einem der abgesicherten Server.
• Die Datei aus RevokedKeys existiert tatsächlich, und ihr habt einmal geprüft, dass ein gesperrtes Zertifikat wirklich abgewiesen wird.
• Die Uhren von Server und Arbeitsgerät gehen synchron, und beim Signieren ist ein kleiner Vorlauf wie -5m gesetzt.
• Ihr wisst, wie ihr auf den Server kommt, wenn SSH gar nicht mehr geht — Konsole beim Anbieter, IPMI, Bildschirm und Tastatur. Und sshd -t läuft vor jedem reload fehlerfrei durch.
• Es ist notiert, welche Zertifikate mit welcher Seriennummer und Laufzeit ausgestellt wurden. Ohne diese Notiz ist gezieltes Widerrufen später Raten.

Fazit: Zertifikate lösen ein Verteilproblem, kein Vertrauensproblem

SSH-Zertifikate nehmen euch die Arbeit ab, die eigentliche Frage aber nicht. Ein Zugang muss nicht mehr an dreissig Stellen gepflegt und an dreissig Stellen wieder entfernt werden; er entsteht an einer und verschwindet von allein. Der Gewinn wächst mit der Zahl der Rechner und Personen.

Was sie nicht lösen, ist die Frage, wem ihr eigentlich vertraut. Die verschiebt sich nur — vom einzelnen Schlüssel auf den einen Schlüssel, der alle anderen unterschreibt. Ein Zertifikat ist eine Aussage, keine Prüfung: Es sagt, dass jemand mit dem CA-Schlüssel diesen Zugang gutgeheissen hat. Ob das eine gute Entscheidung war, steht nicht drin.

Genau deshalb ist die entscheidende Massnahme dieser Anleitung nicht der Signierbefehl, sondern der USB-Stick im Schrank. Alles andere ist Handwerk und in zwei Stunden erledigt. Wer die CA dagegen ohne Passphrase auf dem Rechner liegen lässt, von dem aus er ohnehin ständig arbeitet, hat sich die Mühe gespart — und mit ihr die Sicherheit.

Quellen und weiterführende Links

• ssh-keygen(1) — Abschnitte CERTIFICATES und KEY REVOCATION LISTS, alle Schalter zum Signieren und Widerrufen.
• sshd_config(5) — TrustedUserCAKeys, HostCertificate, AuthorizedPrincipalsFile, AuthorizedPrincipalsCommand, RevokedKeys, CASignatureAlgorithms.
• sshd(8) — Aufbau von authorized_keys und known_hosts samt der Marker @cert-authority und @revoked.
• ssh_config(5) — CertificateFile und das automatische Laden von -cert.pub neben IdentityFile.
• ssh(1) — Optionen des Clients, unter anderem -i und die Ausgabe von -v.
• OpenSSH 5.4 Release Notes vom 08.03.2010 — die Ankündigung der Zertifikatsunterstützung im Wortlaut.
• PROTOCOL.certkeys — die Formatbeschreibung, Begründung gegen X.509, Liste der critical options und extensions.
• OpenSSH-Projektseite — Quelltext, Release Notes und Sicherheitshinweise; aktuell ist dort OpenSSH 10.5 vom 11.08.2026 verzeichnet.
• Auf yourdevice.ch: Sicher per SSH einloggen, Server SSH Zugang mit YubiKey absichern, systemd-Timer statt Cronjob und Unterwegs sicher und stabil arbeiten mit SSHFS.

The post SSH-Zertifikate: eine eigene SSH-CA einrichten appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Der Artikel ist lang. Das ist Absicht: Er soll die Antwort ersetzen, nicht ergänzen. Lest quer, springt in die Stufe, die euch gerade betrifft, und nehmt den Rest, wenn ihr so weit seid.

Warum „Privatsphäre schützen" keine Liste mit zehn Apps ist

Die verbreitetste Form dieses Ratschlags ist eine Aufzählung: Nimm diesen Browser, dieses VPN, diesen Messenger, fertig. Das Problem daran ist nicht, dass die Empfehlungen falsch wären. Das Problem ist, dass sie ohne Reihenfolge kommen — und dass die meisten Leute deshalb bei Punkt drei aufhören, mit einem VPN-Abo, einem halb eingerichteten Messenger und weiterhin demselben Passwort auf vierzig Seiten.

Warum es sich überhaupt lohnt, haben wir in der Infozentrale ausgebreitet — das ist die Seite für alle, die erst noch überzeugt werden wollen. Hier setzen wir voraus, dass ihr überzeugt seid, und kümmern uns um das Wie.

Die erste Frage lautet: vor wem?

Fachleute nennen das ein Bedrohungsmodell, und das klingt nach mehr, als es ist. Es bedeutet nur: aufschreiben, wer sich für eure Daten interessiert und was passieren würde, wenn er sie bekommt. Die Antwort fällt sehr unterschiedlich aus, und daran hängt alles Weitere.

Für die allermeisten geht es um kommerzielle Profilbildung: Werbenetzwerke, Datenhändler, die Auswertung von Standort, Kaufverhalten und Kontakten. Dagegen hilft technische Hygiene, und zwar erstaunlich gut. Für andere geht es um staatlichen Zugriff — dann wird es unbequemer, weil Rechtsräume ins Spiel kommen. Der CLOUD Act und FISA Section 702 erklären, warum „liegt auf einem Server in Zürich" nichts heisst, solange der Anbieter amerikanisch ist. Und wer wissen will, was aus solchen Daten am Ende gebaut wird, findet das in unserem Stück über Palantir.

Ein dritter Fall wird oft übersehen und ist der häufigste von allen: Leute, die euch kennen. Ein Ex-Partner, ein neugieriger Nachbar, ein Kollege mit Zugriff auf euren entsperrten Rechner. Dagegen hilft kein VPN, sondern eine Bildschirmsperre, eine verschlüsselte Festplatte und ein Passwortmanager.

Drei Leute, drei Antworten

Die Familie mit NAS im Keller. Fotos, Steuerunterlagen, Kalender. Grösstes Risiko ist nicht der Geheimdienst, sondern der Ausfall der Festplatte und ein aus dem Internet erreichbares NAS-Login ohne zweiten Faktor. Priorität: Backups und Zugangsschutz.

Der Selbständige mit Kundendaten. Hier kommt eine rechtliche Dimension dazu — Kundendaten in einer amerikanischen Cloud sind ein Thema, das euch irgendwann jemand stellt. Priorität: wissen, wo die Daten liegen, und die wichtigsten Dienste in die eigene Hand nehmen.

Wer einfach genug hat vom Ausgewertetwerden. Kein akutes Risiko, aber der begründete Wunsch, nicht mehr Rohstoff zu sein. Priorität: Smartphone und Browser, weil dort die meisten Daten anfallen.

Wenn ihr euch in keinem davon wiederfindet: auch gut. Nehmt trotzdem Stufe 1, die gilt für alle.

Die Reihenfolge, in der sich der Aufwand lohnt

Wir sortieren nach einem einzigen Kriterium: Wirkung geteilt durch Aufwand. Deshalb steht der Passwortmanager vor dem entgoogelten Smartphone, obwohl das Smartphone das grössere Datenleck ist. Der Manager ist an einem Abend erledigt und schützt sofort; der Gerätewechsel ist ein Wochenende und ein bisschen Gewöhnung.

Wer die Stufen überspringt, baut auf Sand. Ein GrapheneOS-Telefon mit dem Passwort „Sommer2024!" auf allen Konten ist kein sicheres Setup, sondern ein teures.

Stufe 1: die Grundlagen, die für alle gelten

Diese Stufe kostet zusammen etwa einen Abend und wirkt bei jedem, egal welches Gerät, egal welches Betriebssystem. Wenn ihr nur eine Stufe macht, macht diese.

Ein Passwortmanager, und zwar nur einer

Der grösste einzelne Gewinn im ganzen Artikel. Nicht weil Passwörter spannend wären, sondern weil das Gegenteil so verheerend ist: Ein Passwort, das ihr auf mehreren Seiten benutzt, ist genau so sicher wie die schlechteste dieser Seiten. Und irgendeine davon wird gehackt — nicht vielleicht, sondern irgendwann.

Wie das praktisch läuft, steht in unserer Anleitung zu Bitwarden. Wer den Tresor nicht bei einem Anbieter liegen haben will, nimmt Vaultwarden, eine quelloffene, zu den Bitwarden-Apps kompatible Serverfassung — die ist ausdrücklich für Selbstbetrieb gedacht, weil das offizielle Serverpaket dafür zu schwer ist. Und wer sie weder mieten noch selbst betreiben mag: Wir betreiben eine, sie ist kostenlos nutzbar, und ihr könnt jederzeit exportieren und gehen.

Drei Regeln, mehr braucht es nicht: ein langes, einzigartiges Hauptpasswort, das ihr euch merkt. Alle anderen Passwörter erzeugt der Manager und ihr seht sie nie. Und den Notfallzugang — Wiederherstellungscodes, Exportdatei — druckt ihr aus und legt ihn dorthin, wo ihr auch euren Pass aufbewahrt.

Zwei Faktoren, ohne Google

Ein zweiter Faktor macht ein gestohlenes Passwort weitgehend wertlos. Nur bitte nicht per SMS, wenn es sich vermeiden lässt: Eine Rufnummer lässt sich mit erstaunlich wenig Aufwand übernehmen. Nehmt eine App, die die Codes lokal erzeugt — Aegis tut genau das, ist quelloffen und lässt sich verschlüsselt sichern. Der Google Authenticator kann dasselbe, verlangt dafür aber ein Google-Konto, was hier eher gegen den Zweck arbeitet.

Bei Passkeys lohnt ein zweiter Blick, bevor ihr umstellt: Sie sind technisch gut und binden euch gleichzeitig enger an eine Plattform. Was dafür und was dagegen spricht, haben wir in Passkeys — Vor- und Nachteile auseinandergenommen.

Browser und Suchmaschine

Der Browser ist das Werkzeug, mit dem ihr die meisten Spuren hinterlasst. Firefox mit einer Handvoll Erweiterungen deckt den grössten Teil ab; welche das sind, steht in Die besten Extensions für den Firefox Browser. Wer weiter gehen will, findet in Firefox absichern mit AppArmor und user.js die härtere Fassung.

Ein häufiger Anfängerfehler ist dabei, es zu gut zu meinen. Zwanzig Datenschutz-Erweiterungen machen euren Browser nicht anonymer, sondern einzigartiger — und damit besser wiedererkennbar. Warum das so ist, erklärt Browser-Fingerprinting. Wenig und dafür richtig schlägt viel.

Praktisch im Alltag sind ausserdem Multi-Account-Container: Damit sitzt das soziale Netzwerk in einem eigenen Abteil und sieht nicht, was ihr sonst noch aufmacht. Bei der Suchmaschine gibt es mehr Auswahl, als die meisten denken — unsere fünf Alternativen zur Google-Suche gehen die Kandidaten durch, und weil die Frage regelmässig kommt: Sammelt Mozilla Daten oder zensiert DuckDuckGo? ordnet die üblichen Vorwürfe ein.

Nebenbei: Selbst eine Schriftart kann petzen. Google Fonts lädt bei jedem Seitenaufruf nach — und überträgt dabei eure IP-Adresse an Google, ohne dass ihr etwas anklickt.

DNS: die Spur, an die niemand denkt

Jedes Mal, wenn euer Gerät eine Adresse aufruft, fragt es zuerst einen Namensserver, wo die Seite liegt. Diese Anfragen laufen standardmässig unverschlüsselt und beim Internetanbieter — eine vollständige Liste eurer Aufrufe, ganz ohne Cookies. Das lässt sich in zehn Minuten abstellen, und die Anleitung dazu deckt alle drei Systeme ab: DNS-Verschlüsselung auf Linux, Android und Windows.

Einen passenden Server müsst ihr nicht suchen: Wir betreiben einen freien DNS-Server in der Schweiz, mit Verschlüsselung und Filterlisten gegen Werbung und Tracker. Wer lieber im eigenen Netz filtert, findet in Pi-hole auf dem Raspberry Pi den Weg dorthin — das wirkt dann auch auf Geräten, die sich nicht konfigurieren lassen, vom Fernseher bis zur Waschmaschine.

Backups, und zwar vor allem anderen

Das klingt nach dem falschen Thema, ist aber die Voraussetzung für alles, was danach kommt. Wer bei einem Systemwechsel Angst um seine Daten hat, macht den Wechsel nicht — und bleibt aus lauter Vorsicht bei dem, was ihn ausliest. Ein geprüftes Backup ist die Erlaubnis, Dinge auszuprobieren.

Die Grundregel steht in Was ist ein gutes Backup: die 3-2-1-Regel erklärt. Drei Kopien, zwei verschiedene Medien, eine ausser Haus. Und die einzige Frage, auf die es ankommt: Habt ihr schon einmal versucht, aus diesem Backup etwas zurückzuholen? Ein Backup, das nie zurückgespielt wurde, ist eine Vermutung.

Betrugsmails erkennen

Die meisten Konten gehen nicht durch technische Angriffe verloren, sondern weil jemand seine Zugangsdaten auf einer nachgebauten Seite eingibt. Unsere Übersicht zu Betrugs-, Phishing-Mails und SMS zeigt die Merkmale. Die wirksamste Gewohnheit ist dabei simpel: Links in Mails grundsätzlich nicht anklicken, sondern die Seite selbst im Browser aufrufen. Kostet drei Sekunden und erledigt die halbe Kategorie.

Stufe 2: das Smartphone ist die grösste Wanze

Es ist immer dabei, es kennt euren Standort, eure Kontakte, eure Gewohnheiten und eure Uhrzeiten. Kein anderes Gerät liefert ein so vollständiges Bild. Deshalb ist es die Stufe mit dem grössten Hebel — und leider auch die mit der grössten Umstellung.

Der konsequente Weg: ein Gerät ohne Google

Ein alternatives Android-Betriebssystem ersetzt die Herstellerfassung durch eine, die ohne Google-Dienste läuft. Warum das mehr bringt als jede Einstellung im Google-Konto, steht auf unserer Seite Googlefreie Smartphones; welche Systeme es gibt und wie sie sich unterscheiden, in Welches CustomROM?.

Die beiden Systeme, die wir empfehlen, sind GrapheneOS und CalyxOS. GrapheneOS ist die härtere Wahl und läuft ausschliesslich auf Pixel-Geräten — das Projekt begründet das in seiner FAQ damit, dass Geräte nach ihren Eigenschaften ausgewählt werden und nicht nach möglichst breiter Abdeckung. Wer Google-Apps trotzdem braucht, kann sie dort als normale, eingesperrte App nachinstallieren, statt sie im System zu haben. Unser GrapheneOS-Einsteiger-Guide führt durch die Einrichtung, und Hat Google Zugriff auf Pixel-Phones mit GrapheneOS? beantwortet die Frage, die dabei jeder stellt.

CalyxOS unterstützt daneben auch Fairphone- und Motorola-Geräte; die aktuelle Geräteliste führt das Projekt selbst, gestaffelt nach Unterstützungsdauer. Der CalyxOS-Einsteiger-Guide zeigt die Einrichtung. Ob euer Gerät überhaupt in Frage kommt, klärt vorher unsere Kompatibilitätsliste — nicht jedes Telefon lässt sich entsperren, und ohne entsperrbaren Bootloader endet die Sache, bevor sie anfängt.

Zwei Systeme, die im Netz oft empfohlen werden, empfehlen wir ausdrücklich nicht, und wir haben beides begründet: Warum Murenas /e/OS eine Mogelpackung ist und VollaOS: Datenschutz-Marketing gegen technische Realität. Datenschutz auf der Verpackung ist keine Eigenschaft des Produkts.

Der kleine Weg: beim Gerät bleiben und aufräumen

Nicht jeder will oder kann das Gerät wechseln. Das ist kein Grund, gar nichts zu tun — es bringt nur weniger, und das gehört ehrlich dazugesagt. Der Weg für Geräte, die bei der Herstellerfassung bleiben, steht in Privatsphäre auf Android schützen: Aktivitätsverläufe abschalten, personalisierte Werbung deaktivieren, Standortberechtigungen pro App durchgehen.

Deutlich weiter kommt ihr mit unserem zweiteiligen Workshop Android zähmen: Debloating und Firewalling. Vorinstallierte Apps loswerden, ohne das Gerät zu rooten, und einzelnen Apps den Netzzugang entziehen — dafür braucht es keine neue Firmware. Eine lokale Firewall wie ReThink zeigt euch nebenbei zum ersten Mal, wie oft eure Apps eigentlich nach Hause telefonieren. Diese Liste ist für die meisten ein Erlebnis.

Und eine Kleinigkeit mit grosser Wirkung, die auf jedem Gerät funktioniert: WLAN-Tracking unterbinden. Ein Telefon, das ständig nach bekannten Netzen ruft, lässt sich quer durch eine Innenstadt verfolgen.

Apps ohne Play Store

Ein Telefon ohne Google-Konto braucht einen anderen Weg zu Apps. Drei Wege haben sich bewährt, und sie schliessen sich nicht aus.

F-Droid ist ein Katalog ausschliesslich freier Software — das Projekt beschreibt sich selbst als vertrauenswürdiger Weg, quelloffene Android-Apps zu finden und zu teilen. Die Einrichtung steht in F-Droid Installation und Anwendung, und weil das Projekt nicht unumstritten ist, haben wir die Sicherheitsbedenken ebenfalls aufgeschrieben statt sie zu übergehen.

Für Apps, die es nur im Play Store gibt, gibt es den Aurora Store — der holt sie ohne eigenes Google-Konto. Und Obtainium zieht Apps direkt von der Seite des Entwicklers und hält sie aktuell, was besonders bei Software praktisch ist, die in keinem Katalog steht. Womit ihr euer Telefon dann füllt, steht in Die besten Android Open Source Apps.

Ein Hinweis, der in den nächsten Monaten wichtig wird: Google baut die App-Verteilung um und verlangt künftig, dass Entwickler sich verifizieren lassen — auch für Apps, die nie durch den Play Store laufen. Was das bedeutet, steht in Android-Entwickler-Verifizierung: euer Gerät ist egal. Das ist kein Grund, jetzt nichts zu tun, aber ein Grund, die Entwicklung im Auge zu behalten.

Benachrichtigungen ohne Google Push

Hier scheitern die meisten Umsteiger, und zwar an etwas Unerwartetem: Die Nachrichten kommen nicht mehr an. Der Grund ist, dass fast jede App ihre Benachrichtigungen über Googles Push-Dienst schickt — der auf einem entgoogelten Gerät fehlt. Was dieser Dienst tut und was er dabei mitliest, steht in Was ist Google Push?.

Die Lösung heisst UnifiedPush: ein offener Ersatz, bei dem ihr bestimmt, über welchen Server die Benachrichtigungen laufen. Wir betreiben einen, den ihr kostenlos eintragen könnt. Für Signal braucht es zusätzlich einen kleinen Vermittler, und auch den stellen wir bereit. Die Einrichtung auf dem Gerät zeigen Molly FOSS mit UnifiedPush und Element ohne Google Push.

Die Standardapps ersetzen

Karten, Videos, Gerätesuche — für alles, was ihr täglich benutzt, gibt es einen Ersatz, der ohne Konto auskommt.

Bei der Gerätesuche gilt derselbe Gedanke wie beim Push: Ihr braucht einen Server, der die Standortmeldungen entgegennimmt. Auch den betreiben wir kostenlos, damit dieser eine fehlende Baustein nicht den ganzen Umstieg blockiert.

Was ihr beim Umzug nicht verliert

Die häufigste Sorge vor dem Wechsel: „Und meine Bilder? Und die Kontakte? Und die zwölf Jahre WhatsApp?" Der Umzug ist gelöst, und zwar schriftlich. Daten auf ein CustomROM übertragen deckt den Hauptteil ab, Kontakte und SMS von Android oder iPhone übertragen den Rest — auch von einem iPhone aus.

Für danach: Ein CustomROM lokal sichern und wiederherstellen. Macht das einmal, bevor ihr es braucht.

Stufe 3: der Computer

Auf dem Rechner ist der Hebel kleiner als beim Telefon — er ist nicht immer dabei und weiss weniger über euren Tagesablauf. Dafür ist der Umstieg technisch einfacher und leichter rückgängig zu machen.

Warum Linux, und für wen nicht

Die Argumente stehen auf unserer Seite Warum Linux. Die Kurzfassung: kein Telemetrie-Kanal, den ihr nicht abschalten könnt, keine Werbung im Startmenü, keine Konto-Pflicht — und ein zehn Jahre alter Laptop, der wieder benutzbar wird. Wie das aussieht, zeigt Alte Computer mit Linux wieder fit machen.

Ehrlich bleiben gehört dazu: Wer beruflich auf Adobe, bestimmte CAD-Programme oder eine Branchensoftware angewiesen ist, wird damit unter Linux keine Freude haben. Das ist ein Argument gegen Linux auf diesem Rechner, kein Argument gegen Linux. Ein zweiter, älterer Laptop für alles Private ist oft die bessere Lösung als ein halbherziger Komplettumstieg.

Welche Distribution — und erst einmal ausprobieren

Bevor ihr irgendetwas installiert: Linux online ausprobieren kostet nichts und braucht keinen USB-Stick. Danach hilft Welches Linux passt zu mir bei der Auswahl, ausführlicher wird es in Welches Linux-Betriebssystem?. Ob eure Hardware mitspielt, klärt Auf welcher Hardware läuft Linux.

Für den eigentlichen Wechsel gibt es einen Leitfaden von vorne bis hinten: Umstieg von Windows auf Linux. Und die Frage, die immer als erste kommt, ist dort auch beantwortet: Braucht Linux einen Virenschutz?

Die Festplatte verschlüsseln

Der Punkt, der gegen die realistischste Bedrohung hilft: einen gestohlenen oder liegengelassenen Laptop. Ohne Verschlüsselung ist die Anmeldung am System nur eine Tür in einem Haus ohne Wände — die Platte lässt sich ausbauen und an einem anderen Rechner auslesen. Was LUKS ist und wann es sich lohnt, steht in Was ist LUKS, das nachträgliche Verschlüsseln in Home-Ordner nachträglich verschlüsseln. Für einzelne Container und für Windows-Rechner gibt es VeraCrypt.

Vor jedem dieser Schritte gilt Stufe 1: erst das Backup, dann die Verschlüsselung. In dieser Reihenfolge, nicht andersherum. Für den Rückweg nach einem missglückten Update ist TimeShift zuständig, für die regelmässige Sicherung Linux-PC lokal und auf NAS sichern.

Stufe 4: Kommunikation

Messenger: der Inhalt ist längst nicht das Problem

Fast alle grossen Messenger verschlüsseln die Inhalte inzwischen. Das ist gut und lenkt gleichzeitig von der eigentlichen Frage ab: Wer redet wann wie lange mit wem? Diese Metadaten sagen mehr aus als die meisten Gespräche selbst, und sie sind nicht verschlüsselt. Warum das so ist, steht in Metadaten bei Messengern — der wichtigste Artikel in diesem Abschnitt, auch wenn er der unbequemste ist.

Bei WhatsApp kommt hinzu, dass die Verschlüsselung weniger verspricht, als der Werbetext nahelegt; wir haben das in Warum WhatsApps Verschlüsselung eine Verarsche ist auseinandergenommen, und inzwischen beschäftigt die Frage auch ein Gericht.

Praktisch heisst das: Signal ist für die meisten der vernünftige Kompromiss — gute Verschlüsselung, wenig gespeicherte Metadaten, und alle Bekannten sind mit einer Rufnummer erreichbar. Wer die Rufnummer nicht hergeben will, landet bei Matrix, das ohne Telefonnummer auskommt und auf beliebigen Servern läuft. Wir betreiben einen öffentlichen Matrix-Server samt Weboberfläche; wie ihr dazukommt, steht auf unserer Chat-Seite. Dieselbe Logik in gross erklärt Was ist das Fediverse.

E-Mail

E-Mail ist alt, offen und wird das bleiben. Ein Anbieterwechsel bringt trotzdem einiges — unsere Übersicht der fünf privatsphäreorientierten Anbieter nennt die Kandidaten und ihre Haken. Wichtig zu wissen: Verschlüsselt ist damit die Verbindung und die Ablage beim Anbieter, nicht die Mail selbst. Dafür braucht es OpenPGP, auf dem Telefon entsprechend so. Das lohnt sich für einzelne Empfänger, nicht für den ganzen Posteingang — und wer es benutzt, braucht ein Gegenüber, das mitmacht.

Als Programm empfehlen wir Thunderbird auf dem Rechner und K-9 Mail auf dem Telefon. Für Anmeldungen bei Diensten, denen ihr nicht traut, haben wir einen Wegwerf-Mail-Dienst — mit einer wichtigen Einschränkung, die dort auch steht: Diese Postfächer sind öffentlich lesbar, sobald jemand die Adresse kennt. Für Newsletter und Einmal-Registrierungen gut, für alles andere nicht.

Videokonferenz

Für Besprechungen ohne Konto und ohne Installation gibt es Jitsi Meet. Unseren Server könnt ihr ohne Anmeldung benutzen: Link erzeugen, verschicken, fertig. Das ist der Punkt, an dem die meisten merken, dass „datenschutzfreundlich" nicht zwangsläufig „umständlich" heisst.

VPN und Tor: was sie leisten und was nicht

Diese beiden Werkzeuge werden häufiger empfohlen als verstanden, und sie stehen hier bewusst nicht in Stufe 1. Sie lösen ein eng umrissenes Problem sehr gut und alle anderen Probleme gar nicht.

Ein VPN verschiebt Vertrauen, es erzeugt keine Anonymität

Ein VPN sorgt dafür, dass euer Internetanbieter nicht mehr sieht, welche Seiten ihr aufruft. Stattdessen sieht es der VPN-Anbieter. Das ist ein Tausch, kein Zugewinn — und ob er sich lohnt, hängt allein davon ab, wem ihr weniger traut. Die ausführliche Fassung steht in Bin ich mit einem VPN anonym?. Kurz: nein. Wer bei Google angemeldet surft, ist mit VPN genau so identifiziert wie ohne, nur mit anderer IP-Adresse.

Sinnvoll ist ein VPN im fremden WLAN, gegen die Auswertung durch den eigenen Anbieter und für den Zugriff auf das eigene Netz von unterwegs. Und für diesen letzten Zweck — den mit Abstand häufigsten — braucht ihr gar keinen Anbieter, sondern einen eigenen Server: Wireguard betreiben oder, wenn ein NAS im Haus steht, den VPN-Server auf der Synology. Dann führt der Tunnel nach Hause statt zu einer Firma, deren Werbeversprechen niemand prüfen kann.

Tor

Tor löst das Problem, das ein VPN nicht löst: Es gibt keine einzelne Stelle, die gleichzeitig weiss, wer ihr seid und was ihr aufruft. Wie das funktioniert, steht in Was ist das Tor-Netzwerk. Den Tor Browser gibt es für Windows, macOS, Linux und Android; für iOS verweist das Projekt auf den Onion Browser.

Der ehrliche Teil: Tor ist langsam, manche Seiten sperren es aus, und es ist kein Zauber. Unsere technische Einordnung der BKA-Timing-Attacke zeigt, wo die Grenzen liegen — und auch, dass die Berichterstattung dazu deutlich dramatischer war als der Sachverhalt. Für Recherche, für Themen, bei denen euch niemand über die Schulter schauen soll, und für den Zugang zu gesperrten Inhalten ist Tor das richtige Werkzeug. Zum täglichen Einkaufen nicht.

Tor auf dem Smartphone: Orbot und der Tor Browser

Auf Android gibt es zwei Wege. Der Tor Browser leitet nur den Browser durch das Netz. Orbot geht weiter und legt sich als Tunnel vor das ganze Gerät oder wahlweise vor einzelne Apps — die Anleitung dazu steht in Orbot: Daten über das Tor-Netzwerk verschlüsseln. Wie ihr einzelne Messenger hindurchschickt, zeigt Telegram, Signal oder WhatsApp über Tor. Auf Linux macht Oniux dasselbe für einzelne Programme.

Eine Warnung, die viel Ärger erspart: Ein Konto, das euren Namen trägt, bleibt euer Konto — auch über Tor. Was das für die üblichen Plattformen bedeutet, steht in Kann ich Social Media anonym benutzen?.

Der NAS, den ihr vielleicht schon habt

Erstaunlich viele, die uns schreiben, haben bereits ein NAS im Keller stehen — meistens eine Synology. Das ist ein guter Ausgangspunkt und gleichzeitig das Gerät, bei dem am häufigsten etwas schiefliegt.

Vier Dinge, in dieser Reihenfolge. Erstens: Zwei-Faktor-Authentifizierung einschalten. Ein NAS-Login, das aus dem Internet erreichbar ist und nur ein Passwort hat, wird angegriffen — nicht vielleicht, sondern täglich und automatisiert. Zweitens: Das Verwaltungsinterface gehört nicht ins offene Internet. Nehmt stattdessen einen VPN-Zugang, dann ist das NAS von unterwegs erreichbar, ohne dass es die halbe Welt anschauen kann. Wer eine feste Adresse dafür braucht, findet sie in DynDNS für Synology.

Drittens: Ein externes Backup. Ein NAS ist kein Backup, auch nicht mit RAID — RAID schützt gegen eine kaputte Platte, nicht gegen Verschlüsselungstrojaner, Blitzschlag oder eine versehentlich gelöschte Ordnerstruktur. Viertens, wenn ihr Lust habt: Nextcloud auf der Synology. Damit ersetzt ein Gerät, das ihr schon habt, Google Drive, den Kalender und die Kontaktsynchronisation.

Für alle, die weiter aufteilen wollen: VLANs trennen das Heimnetz in Bereiche, sodass der smarte Fernseher nicht im selben Segment sitzt wie die Buchhaltung. Was ist eine Firewall liefert die Grundlagen dazu. Und wenn Daten trotz allem bei einem Cloud-Anbieter liegen müssen, hilft Daten in der Cloud verschlüsseln: Was verschlüsselt hochgeht, ist dem Anbieter egal.

Selber hosten oder nutzen, was schon läuft

An dieser Stelle kommt bei fast allen dieselbe Frage: Muss ich dafür jetzt einen Server betreiben? Nein. Es gibt drei Wege, und sie lassen sich beliebig mischen.

Weg eins: benutzen, was bei uns schon läuft

Wir betreiben über zwanzig Dienste auf eigenen Servern, überwiegend in der Schweiz, und sie sind kostenlos nutzbar — für Kundschaft wie für Leser. Die vollständige Liste steht auf Unsere Server für mehr Privatsphäre. Die für den Einstieg nützlichsten haben wir oben schon genannt; hier der Überblick.

• Nextcloud — Dateien, Kalender, Kontakte und Aufgaben. 4 GB für Leser, 10 GB für Kundschaft.
• Immich — Foto- und Videocloud mit automatischem Upload vom Telefon, 3 GB gratis.
• Vaultwarden — Passwortmanager, kompatibel mit den Bitwarden-Apps.
• Freier DNS-Server — verschlüsselt, mit Filterlisten.
• UnifiedPush und MollySocket — Benachrichtigungen ohne Google.
• Find My Device — Gerätesuche ohne Google-Konto.
• Jitsi Meet — Videokonferenz ohne Anmeldung.
• Matrix-Chatserver — Messenger ohne Telefonnummer.
• Dateiverschlüsselung im Browser — verschlüsseln, bevor etwas irgendwo hochgeht.
• Linkwarden für Lesezeichen und ein Übersetzer-Frontend ohne Konto.

Für die meisten dieser Dienste braucht ihr weder ein Konto noch eine Anmeldung bei uns; bei Nextcloud, dem Chatserver und einigen weiteren geht es nicht ohne. Wir verlangen dafür nichts und wir wollen dafür auch nichts — ausser vielleicht, dass ihr uns Bescheid gebt, wenn etwas nicht läuft.

Weg zwei: selbst hosten

Wer die Kontrolle wirklich will, betreibt die Dienste selbst — auf einem Mini-PC, einem Raspberry Pi oder dem NAS, das ohnehin schon läuft. Was Nextcloud ist und was es ersetzt, erklärt unsere Seite Was ist Nextcloud. Der übliche Unterbau dafür ist Docker, und den Einstieg dazu liefert Docker Basics.

Zwei Dinge braucht ihr fast immer. Erstens einen Reverse Proxy, damit die Dienste unter ordentlichen Adressen und mit gültigen Zertifikaten erreichbar sind: Caddy einrichten. Zweitens eine Aufgabenplanung, die euch meldet, wenn eine Sicherung nicht durchgelaufen ist — dafür haben wir gerade erst systemd-Timer statt Cronjob geschrieben. Und wenn ihr schon dabei seid, den Papierkram gleich mit: Paperless-ngx einrichten macht aus dem Ordner mit den Rechnungen ein durchsuchbares Archiv, das im Haus bleibt.

Ehrlicherweise gehört dazu: Selbst hosten heisst, dass ihr ab jetzt der Systemadministrator seid. Updates, Backups, ein Dienst, der um drei Uhr nachts stehenbleibt. Das ist machbar und für viele sogar unterhaltsam — aber es ist eine Verpflichtung und kein einmaliger Nachmittag.

Weg drei: einrichten lassen

Wenn ihr das Ergebnis wollt, aber nicht den Weg dorthin, machen wir das. Was wir installieren und wie das abläuft, steht auf Open-Source-Services für euer Zuhause oder euer Unternehmen — von der Beratung über die Hardware bis zur Einweisung, für Privathaushalte wie für kleinere Betriebe, vor Ort oder aus der Ferne. Der praktische Vorteil des Wegs: Ihr könnt sämtliche Dienste vorher auf unseren Servern ausprobieren und erst danach entscheiden, was ihr davon bei euch stehen haben wollt.

Eine Bitte in eigener Sache: Für persönliche Einrichtungsfragen per Mail fehlt uns schlicht die Zeit — es sind zu viele. Was es dafür gibt, ist unser Chatserver, und der funktioniert erfahrungsgemäss besser als eine Mail an uns: Dort sitzen Leute, die dieselbe Umstellung vor sechs Monaten hinter sich gebracht haben. Wir sind auch dort unterwegs.

Die Fehler, die wir am häufigsten sehen

Alles auf einmal. Neues Telefon, neues Betriebssystem, neuer Messenger, neuer Mailanbieter, alles an einem Wochenende. Danach funktioniert irgendetwas nicht, und weil vier Dinge gleichzeitig neu sind, findet niemand mehr heraus, welches. Eine Sache pro Woche reicht völlig.

Das VPN zuerst. Es ist die sichtbarste Massnahme und deshalb die beliebteste. Nur ändert sie am wenigsten, solange die Grundlagen fehlen.

Werbung glauben statt nachschauen. „Datenschutzfreundlich" ist keine geschützte Bezeichnung und kostet in der Herstellung genau nichts. Unsere Artikel zu /e/OS und VollaOS zeigen den Unterschied zwischen Versprechen und Nachprüfung.

Kein Rückweg eingeplant. Bevor ihr ein Telefon neu aufsetzt oder eine Platte verschlüsselt: Backup, und einmal testweise zurückgeholt. Wer diesen Schritt überspringt, spart zwanzig Minuten und riskiert einen Abend.

Die eigenen Leute vergessen. Der beste Messenger nützt nichts, wenn niemand aus eurem Umfeld ihn benutzt. Rechnet damit, dass ihr zwei Anwendungen parallel führt — das ist kein Scheitern, sondern der Normalfall.

Perfektion als Ziel. Es gibt kein vollständig spurenfreies digitales Leben, jedenfalls keines, in dem sich noch angenehm leben lässt. Achtzig Prozent weniger Datenspur bei zwanzig Prozent Aufwand ist ein hervorragendes Ergebnis. Wer die letzten zwanzig Prozent erzwingen will, hört meistens ganz auf — und landet wieder bei hundert.

Womit ihr diese Woche anfangt

Nicht alles, sondern das hier. Vier Abende, verteilt über eine Woche, und ihr habt den grössten Teil der Wirkung mitgenommen.

• Abend 1 — Passwörter. Passwortmanager einrichten, Hauptpasswort festlegen, die zehn wichtigsten Konten umstellen: Mail zuerst, dann Bank, dann der Rest. Die restlichen dreissig macht ihr nebenbei, immer wenn ihr euch irgendwo anmeldet.
• Abend 2 — zweiter Faktor und DNS. Aegis installieren und bei Mail und Bank den zweiten Faktor einschalten. Danach die DNS-Verschlüsselung auf Telefon und Rechner setzen. Zusammen gut eine Stunde.
• Abend 3 — Backup. Einen Sicherungsplan aufsetzen und, das ist der eigentliche Punkt, einmal eine Datei daraus zurückholen. Erst dann habt ihr ein Backup und nicht nur ein Programm.
• Abend 4 — Browser. Firefox mit wenigen, ausgewählten Erweiterungen einrichten, Suchmaschine wechseln, Container für die grossen Plattformen anlegen.

Danach, in Ruhe und in dieser Reihenfolge: das Smartphone, dann der Rechner, dann die Kommunikation. Und wenn ihr wissen wollt, ob sich der Umstieg auf ein anderes Telefon oder auf Linux für euch überhaupt lohnt, ist unser FAQ der schnellste Weg zu einer Antwort — dort stehen die neunundzwanzig Fragen, die Umsteiger tatsächlich stellen, jeweils mit der passenden Anleitung dahinter.

Fazit: Privatsphäre ist eine Reihenfolge, kein Produkt

Es gibt keinen Kauf, der diese Frage erledigt, und keine App, nach deren Installation ihr fertig seid. Es gibt eine Handvoll Gewohnheiten, ein paar Werkzeuge und die Bereitschaft, alle paar Monate einen weiteren Schritt zu machen. Das ist die unspektakuläre Wahrheit hinter einem Thema, zu dem sehr viel spektakulär geschrieben wird.

Die gute Nachricht daran ist, dass der grösste Teil des Gewinns am Anfang steht. Passwortmanager, zweiter Faktor, verschlüsseltes DNS und ein Backup, das funktioniert — das ist ein Abend Arbeit und bringt mehr als jedes VPN-Abo. Der Rest darf dauern.

Und noch etwas: Ihr müsst das nicht allein machen und ihr müsst es nicht perfekt machen. Jeder Dienst, den ihr nicht mehr benutzt, ist ein Profil, das nicht weiterwächst. Das zählt auch dann, wenn drei andere noch laufen.

Quellen und weiterführende Links

Der Ratgeber ist bewusst als Verteiler gebaut. Hier alles noch einmal nach Thema sortiert, damit ihr diesen Abschnitt allein weitergeben könnt.

Warum überhaupt

• Infozentrale — die Ausgangslage
• Der CLOUD Act und FISA Section 702 — warum der Serverstandort allein nichts sagt
• Palantir, die Sehsteine der USA in Europa

Stufe 1: Grundlagen

• Passwortmanager Bitwarden · Vaultwarden (Projekt) · unser Vaultwarden
• Aegis als zweiter Faktor · Passkeys: Vor- und Nachteile
• Firefox-Erweiterungen · Firefox härten · Browser-Fingerprinting · Multi-Account-Container
• Suchmaschinen-Alternativen · Mozilla und DuckDuckGo eingeordnet · Google Fonts
• DNS verschlüsseln · unser DNS-Server · Pi-hole
• Die 3-2-1-Regel · Phishing erkennen

Stufe 2: Smartphone

• Googlefreie Smartphones · Welches CustomROM? · Kompatibilitätsliste
• GrapheneOS FAQ · GrapheneOS-Guide · Hat Google Zugriff?
• CalyxOS Geräteliste · CalyxOS-Guide
• Nicht empfohlen, mit Begründung: /e/OS · VollaOS
• Beim Gerät bleiben: Privatsphäre auf Android · Android zähmen · ReThink-Firewall · WLAN-Tracking
• Apps: F-Droid (Projekt) · F-Droid einrichten · F-Droid: Sicherheitsbedenken · Aurora Store · Obtainium · Die besten Open-Source-Apps · Entwickler-Verifizierung
• Push: Was ist Google Push · Molly FOSS · Element ohne Google Push
• Umzug: Daten übertragen · Kontakte und SMS · Lokale Sicherung · Backup mit Nextcloud
• Ersatz-Apps: Organic Maps · NewPipe · Gerät orten ohne Google

Stufe 3: Computer

• Warum Linux · Linux online ausprobieren · Welches Linux passt zu mir · Welches Linux-Betriebssystem?
• Umstiegs-Leitfaden · Hardware · Alte Rechner · Virenschutz?
• Verschlüsselung und Sicherung: LUKS · Home-Ordner verschlüsseln · VeraCrypt · TimeShift · Sicherung auf NAS

Stufe 4: Kommunikation

• Metadaten bei Messengern · WhatsApp-Verschlüsselung · der Gerichtsfall dazu
• Unser Chatserver · Matrix-Server · Element im Browser · Was ist das Fediverse
• E-Mail: Anbieterübersicht · OpenPGP · OpenPGP auf Android · Thunderbird · K-9 Mail · Wegwerf-Mail
• Jitsi Meet ohne Konto

VPN und Tor

• Bin ich mit einem VPN anonym? · Wireguard selbst betreiben · VPN auf der Synology
• Was ist das Tor-Netzwerk · Tor Browser (Projekt) · BKA-Timing-Attacke eingeordnet
• Orbot (Projekt) · Orbot einrichten · Messenger über Tor · Oniux unter Linux · Social Media anonym?

NAS, eigene Dienste und Einrichtung

• Synology: Zwei-Faktor · DynDNS · externes Backup · Nextcloud auf der Synology
• Netz: VLANs · Firewall · Cloud-Daten verschlüsseln
• Selbst hosten: Was ist Nextcloud · Docker Basics · Caddy · systemd-Timer · Paperless-ngx
• Unsere Angebote: alle kostenlosen Dienste · Einrichtung bei euch
• Weiterlesen: FAQ für Umsteiger · alle Anleitungen · Privacy-Tipps

The post Privatsphäre schützen: der Ratgeber für den Einstieg appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Warum systemd-Timer den Cronjob ablösen

Cron macht genau eine Sache: Es startet zur eingetragenen Zeit einen Befehl. Was danach passiert, interessiert es nicht. Läuft der Befehl auf einen Fehler, landet die Ausgabe im besten Fall in einer lokalen Mail, die niemand liest, und im schlechteren Fall in /dev/null, weil das jemand vor drei Jahren so eingetragen hat, damit das Log nicht zuläuft. Wie diese Umleitung funktioniert, haben wir in stdout, stderr und /dev/null auseinandergenommen – bei Cron ist sie der häufigste Grund, warum ein Fehlschlag unbemerkt bleibt.

Falls ihr Cron bisher klassisch benutzt habt, etwa für die Hintergrundaufgaben einer Nextcloud, kennt ihr die Bedienung aus unserer Anleitung Cronjob für Eure Nextcloud erstellen. Alles, was dort steht, funktioniert weiterhin. Es gibt nur eben inzwischen einen zweiten Weg.

Amazon ist dabei am deutlichsten geworden. In der Dokumentation zu Amazon Linux 2023 steht schwarz auf weiss: „In AL2023, cronie is not included by default. Therefore, support for crontab is no longer provided by default." Und weiter: „We recommend that you migrate to systemd timers due to the added functionality provided by systemd." Nachzulesen in der AL2023-Dokumentation zu Cron. Auf Debian, Ubuntu und Mint ist Cron weiterhin installiert – aber ein wachsender Teil der Systemwartung läuft dort ohnehin schon über Timer-Units, ohne dass es jemand gemerkt hätte.

Der praktische Unterschied lässt sich in eine Tabelle packen:

Die letzte Zeile ist der ehrliche Teil. Wer alle fünf Minuten ein Einzeiler-Skript anstossen will und sonst nichts, ist mit Cron schneller fertig. Für alles, dessen Ausfall wehtut – Sicherungen, Zertifikatserneuerungen, Datenbankpflege – lohnt sich der Mehraufwand ab dem ersten stillen Fehlschlag.

Voraussetzungen und eine Vorwarnung

Ihr braucht ein System mit systemd. Das trifft auf Debian, Ubuntu, Linux Mint, Fedora, openSUSE und Arch zu, also auf praktisch alles, was auf dieser Seite sonst behandelt wird. Prüfen lässt sich das mit:

systemctl --version

Für Units im Systemkontext braucht ihr Root-Rechte. Alle folgenden Befehle mit sudo setzen voraus, dass euer Benutzer das darf. Wer sich bei Benutzern, Gruppen und Rechten unsicher ist, findet die Grundlagen in Linux Gruppen und Berechtigungen einfach erklärt.

Wichtig: Legt eigene Units immer unter /etc/systemd/system/ ab, niemals unter /lib/systemd/system/ oder /usr/lib/systemd/system/. Das zweite Verzeichnis gehört der Paketverwaltung, und das nächste Update überschreibt eure Datei kommentarlos.

Die zwei Dateien: eine Service-Unit und eine Timer-Unit

Ein systemd-Timer führt selbst nichts aus. Er ist ausschliesslich der Wecker; die Arbeit macht eine Service-Unit. Die Handbuchseite systemd.timer(5) beschreibt die Zuordnung so: Ein Timer namens foo.timer aktiviert standardmässig die Unit foo.service, also den gleichen Namen mit anderer Endung. Solange ihr beide Dateien gleich benennt, müsst ihr die Verbindung nirgends eintragen.

Als durchgehendes Beispiel dient eine nächtliche Sicherung des Home-Verzeichnisses. Das eigentliche Skript liege unter /usr/local/bin/backup-home.sh und sei ausführbar.

Schritt 1: Die Service-Unit anlegen

sudo nano /etc/systemd/system/backup-home.service

Inhalt:

[Unit]
Description=Naechtliche Sicherung des Home-Verzeichnisses
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-home.sh
User=mario
Nice=10
IOSchedulingClass=idle

Drei Zeilen verdienen eine Erklärung. Type=oneshot ist der Typ für Aufgaben, die anlaufen, ihre Arbeit tun und sich beenden. Laut systemd.service(5) betrachtet der Dienstmanager die Unit erst dann als gestartet, wenn der Hauptprozess sich beendet hat – „the service manager will consider the unit up after the main process exits". Genau das wollt ihr hier, denn eine Sicherung ist fertig oder nicht.

User=mario lässt das Skript unter eurem Benutzer laufen statt als Root – ersetzt den Namen, und lasst die Zeile weg, falls das Skript Root braucht. Nice=10 und IOSchedulingClass=idle drängen den Job hinter interaktive Arbeit zurück; die Sicherung darf zehn Minuten länger dauern, wenn dafür niemand ruckelt.

Es fehlt eine Zeile, die ihr aus Cron kennt: die Umleitung der Ausgabe. Die braucht es nicht. Alles, was das Skript auf stdout und stderr schreibt, landet ohne Zutun im Journal – so beschreibt es systemd.exec(5) im Abschnitt zu Logging und Standard-Ein- und -Ausgabe.

Schritt 2: Die Timer-Unit anlegen

sudo nano /etc/systemd/system/backup-home.timer

Inhalt:

[Unit]
Description=Startet die naechtliche Home-Sicherung

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
RandomizedDelaySec=900
AccuracySec=1min

[Install]
WantedBy=timers.target

Der Abschnitt [Install] mit WantedBy=timers.target ist der Grund, warum der Timer nach einem Neustart wieder da ist. Fehlt er, lässt sich die Unit zwar starten, aber nicht dauerhaft aktivieren.

Schritt 3: Einlesen und aktivieren

sudo systemctl daemon-reload
sudo systemctl enable --now backup-home.timer

daemon-reload lädt die Konfiguration des Dienstmanagers neu; laut systemctl(1) werden dabei alle Unit-Dateien neu eingelesen und der gesamte Abhängigkeitsbaum neu aufgebaut. Ohne diesen Schritt kennt systemd eure Datei nicht. enable --now aktiviert die Unit und startet sie in einem Aufwasch.

Beachtet: Aktiviert wird der Timer, nicht der Service. Der Service bleibt inaktiv und wird vom Timer geweckt. Ein häufiger Anfängerfehler ist systemctl enable backup-home.service – damit läuft die Sicherung bei jedem Systemstart genau einmal und danach nie wieder.

Testen lässt sich der Ablauf jederzeit, ohne auf zwei Uhr nachts zu warten:

sudo systemctl start backup-home.service
systemctl status backup-home.service

Damit ist die Grundkonstruktion fertig. Wie die drei beteiligten Units zusammenspielen – die dritte kommt weiter unten dazu – zeigt das folgende Schaubild.

OnCalendar: die Zeitsyntax, die kein Cron-Format ist

Hier liegt die grösste Umgewöhnung. OnCalendar= benutzt nicht die fünf Sternchen aus der Crontab, sondern eine eigene Schreibweise. Die Handbuchseite systemd.time(7) beschreibt das Format als Wochentag Jahr-Monat-Tag Stunde:Minute:Sekunde. Der Wochentag darf fehlen, das Datum ebenso; die Uhrzeit ist der Kern.

Die Operatoren sind schnell erzählt. Ein Sternchen passt auf jeden Wert. Mehrere Werte werden mit Komma aufgezählt. Zwei Punkte bilden einen Bereich, etwa Mon..Fri. Der Schrägstrich bedeutet Wiederholung, also *:0/15 für alle fünfzehn Minuten.

Zusätzlich gibt es Kurzformen, die die Handbuchseite ausdrücklich als Abkürzungen ausweist:

Ein paar praktische Ausdrücke, die die meisten Fälle abdecken:

OnCalendar=*-*-* 02:00:00          # jede Nacht um 02:00
OnCalendar=Mon..Fri *-*-* 07:30    # werktags um 07:30
OnCalendar=Sun *-*-* 04:00:00      # sonntags um 04:00
OnCalendar=*-*-01 03:00:00         # am Ersten jedes Monats um 03:00
OnCalendar=*:0/15                  # alle 15 Minuten
OnCalendar=hourly                  # zur vollen Stunde

Mehrere OnCalendar=-Zeilen in derselben Unit sind erlaubt und ergeben mehrere Auslösezeitpunkte. Eine leere Zuweisung OnCalendar= löscht alle bisherigen Angaben – nützlich in Drop-in-Dateien, verwirrend, wenn es unbeabsichtigt passiert.

Den Ausdruck prüfen, bevor ihr ihn einsetzt

Ihr müsst nicht raten. systemd-analyze hat einen Unterbefehl, der genau dafür da ist. Die Handbuchseite systemd-analyze(1) beschreibt ihn so: „This command will parse and normalize repetitive calendar time events, and will calculate when they elapse next."

systemd-analyze calendar "Mon..Fri *-*-* 07:30"

Die Ausgabe nennt die ursprüngliche Form, die normalisierte Form, den nächsten Auslösezeitpunkt und den Abstand bis dahin. Steht dort ein Datum, das euch überrascht, habt ihr euch vertan – und das vor dem Produktivbetrieb statt danach. Verwandt und ebenso nützlich ist systemd-analyze verify /etc/systemd/system/backup-home.service: Der Befehl meldet unbekannte Abschnitte, fehlende Abhängigkeiten und nicht ausführbare Befehle.

Kalenderausdrücke werden in der lokalen Zeitzone des Systems ausgewertet. Auf einem Server, der auf UTC steht, ist „02:00" also nicht eure Bettzeit – ein Blick auf timedatectl vor dem ersten Timer erspart Verwunderung.

Persistent, RandomizedDelaySec und der Rest der Feineinstellung

Die vier Zeilen aus dem Beispiel sind der Punkt, an dem ein Timer den Cronjob inhaltlich überholt. Alle stammen aus dem Abschnitt [Timer] und sind in systemd.timer(5) beschrieben.

Persistent=true speichert den letzten Auslösezeitpunkt auf der Platte. War das System zum geplanten Termin aus, wird der Job unmittelbar nach dem Hochfahren nachgeholt. Das ist die Funktion, für die es unter Cron ein zweites Programm braucht – anacron –, und auf einem Laptop, der nachts um zwei zugeklappt im Rucksack liegt, ist sie der Unterschied zwischen einer Sicherung und einer Sicherungsabsicht.

RandomizedDelaySec=900 verzögert die Ausführung um eine zufällig gewählte, gleichmässig verteilte Zeitspanne zwischen null und dem angegebenen Wert. Wenn zwanzig Maschinen um Punkt zwei Uhr dieselbe Netzwerkfreigabe ansteuern, verteilt das die Last über eine Viertelstunde. Wollt ihr die Verzögerung stabil statt bei jedem Start neu ausgewürfelt, setzt zusätzlich FixedRandomDelay=true: Der Versatz wird dann aus Maschinen-ID und Unit-Namen abgeleitet und bleibt gleich. Wie stark eure Maschine unter solchen Spitzen tatsächlich leidet, seht ihr mit den Werkzeugen aus Nützliche Linux Konsolen Tools für das Systemmonitoring.

AccuracySec= gibt an, wie genau der Timer treffen soll, und steht laut Handbuch standardmässig auf einer Minute. systemd nutzt diese Toleranz, um Aufwachvorgänge zu bündeln und den Rechner länger schlafen zu lassen. Wer es exakt braucht, setzt AccuracySec=1us – und zahlt das mit Stromverbrauch.

Drei weitere Optionen sind gut zu kennen. OnBootSec= definiert einen Zeitpunkt relativ zum Systemstart, OnUnitActiveSec= einen relativ zur letzten Aktivierung der Zieleinheit. Kombiniert ergibt das „fünf Minuten nach dem Start und danach alle sechs Stunden", ohne jeden Kalender:

[Timer]
OnBootSec=5min
OnUnitActiveSec=6h

Und WakeSystem=true weckt das System aus dem Bereitschaftsbetrieb, wenn der Timer fällig wird. Auf einem Server irrelevant, auf einem Heim-NAS mit Ruhezustand entscheidend.

Soll der Timer eine Unit mit abweichendem Namen starten, gebt sie ausdrücklich an – Unit= ist laut Handbuch „the unit to activate when this timer elapses". Nötig ist das nur, wenn ihr von der Namenskonvention abweicht.

Nachsehen, ob es läuft: list-timers und das Journal

Der wichtigste Befehl im Alltag ist eine Übersicht aller Timer, sortiert nach dem nächsten Auslösezeitpunkt:

systemctl list-timers backup-home.timer

Die Ausgabe sieht so aus:

NEXT                 LEFT      UNIT               ACTIVATES
Do 2026-09-03 02:14  19h left  backup-home.timer  backup-home.service

Die Spalten sind in systemctl(1) beschrieben: NEXT zeigt, wann der Timer das nächste Mal läuft, LEFT wie lange es bis dahin dauert, LAST und PASSED dasselbe rückwärts, UNIT den Namen des Timers und ACTIVATES den Dienst, den er startet. Ohne Argument listet der Befehl alle Timer des Systems auf – der schnellste Weg zu sehen, was auf einer fremden Maschine eigentlich alles nachts passiert. systemctl list-timers --all zeigt zusätzlich die inaktiven.

Die 02:14 in der Ausgabe sind übrigens kein Tippfehler: Das ist RandomizedDelaySec bei der Arbeit.

Was der Job beim letzten Lauf gesagt hat, steht im Journal. Die Option -u filtert laut journalctl(1) auf die Meldungen einer bestimmten Unit:

journalctl -u backup-home.service -n 50 --no-pager
journalctl -u backup-home.service --since "-7d" -p warning
journalctl -u backup-home.service -f

Die erste Zeile zeigt die letzten fünfzig Meldungen, die zweite alle Warnungen und Schlimmeres der vergangenen sieben Tage, die dritte hängt sich live an die Ausgabe und läuft bis Strg+C. Wer tiefer in die Fehlersuche einsteigen will, findet den Rest in unserer Anleitung Linux Problembehebung im systemd.

Nützlich ist ausserdem systemctl cat backup-home.timer: Der Befehl zeigt die Unit so, wie systemd sie tatsächlich sieht, samt allen Drop-ins – und beendet jede Diskussion darüber, welche der drei Kopien nun gilt.

Der eigentliche Gewinn: OnFailure meldet den Fehlschlag

Bis hierhin habt ihr einen Cronjob mit mehr Schreibarbeit. Der Unterschied beginnt jetzt. In systemd.unit(5) steht eine Option, die es unter Cron schlicht nicht gibt: OnFailure= ist „a space-separated list of one or more units that are activated when this unit enters the 'failed' state." Anders gesagt: Geht die Sicherung schief, startet systemd von sich aus eine zweite Unit eurer Wahl. Was diese Unit tut, ist euch überlassen – eine Push-Nachricht, eine Mail, ein Eintrag in ein Monitoring.

Eine Benachrichtigungs-Unit als Vorlage anlegen

Damit ihr die Unit nicht für jeden Job neu schreibt, legt ihr sie als Vorlage an. Der Klammeraffe im Dateinamen macht daraus eine Template-Unit, deren Instanzname später den Namen des fehlgeschlagenen Dienstes trägt.

sudo nano /etc/systemd/system/alarm@.service

[Unit]
Description=Meldet den Fehlschlag von %i per ntfy

[Service]
Type=oneshot
ExecStart=/usr/bin/curl -sS \
  -H "Title: Fehlgeschlagen: %i" \
  -H "Priority: 5" \
  -H "Tags: warning" \
  -d "Auf diesem System ist %i fehlgeschlagen. Details mit: journalctl -u %i -n 50" \
  https://ntfy.sh/EUER-LANGES-ZUFALLSTHEMA

Der Platzhalter %i ist in systemd.unit(5) als Instance name definiert: die Zeichenkette zwischen dem ersten @ und der Endung. Ihr braucht die Unit also genau einmal, egal wie viele Jobs sie später melden soll.

Prüft, ob curl überhaupt installiert ist, und ob der Pfad stimmt:

which curl

Liegt es woanders, tragt den tatsächlichen Pfad ein. ExecStart= verlangt einen absoluten Pfad und findet nichts über die PATH-Variable.

Die Vorlage im Job eintragen

Ergänzt den Abschnitt [Unit] eurer Service-Unit um eine Zeile:

[Unit]
Description=Naechtliche Sicherung des Home-Verzeichnisses
Wants=network-online.target
After=network-online.target
OnFailure=alarm@%n.service

%n ist laut Handbuch der full unit name, hier also backup-home.service. Aus alarm@%n.service wird damit die Unit alarm@backup-home.service.service, und in der Benachrichtigung steht %i für backup-home.service. Das sieht auf den ersten Blick nach einem Tippfehler aus und ist genau richtig so.

sudo systemctl daemon-reload

ntfy einrichten und den Alarm testen

ntfy verschickt Push-Nachrichten über einen einfachen HTTP-Aufruf. Die Projektdokumentation zeigt den Aufbau: Der Nachrichtentext geht per -d an eine URL, deren letzter Bestandteil das Thema ist; Titel, Priorität und Schlagwörter werden über die Kopfzeilen Title, Priority und Tags gesetzt. Priorität 5 ist die höchste von fünf Stufen.

Sicherheitshinweis, und der ist ernst gemeint: Bei ntfy gibt es keine Anmeldung für das blosse Senden und Empfangen. Die Projektdokumentation formuliert das unmissverständlich: „the topic is essentially a password", ihr sollt also etwas wählen, das nicht zu erraten ist. Wer backup als Thema nimmt, teilt seine Ausfallmeldungen mit der halben Welt. Nehmt eine lange Zufallszeichenkette, zum Beispiel erzeugt mit head -c 18 /dev/urandom | base64 | tr -d '/+='. Wer den Dienst nicht in fremden Händen haben will, betreibt ntfy selbst – der Server ist quelloffen und in einem Container schnell aufgesetzt.

Installiert die ntfy-App auf dem Smartphone, abonniert dort euer Thema und löst dann absichtlich einen Fehler aus. Am einfachsten geht das mit einer Wegwerf-Unit:

sudo systemd-run --unit=alarmtest --property=OnFailure=alarm@alarmtest.service /bin/false

/bin/false beendet sich mit einem Fehlerstatus, die Unit geht damit in den Zustand failed, und das Telefon sollte klingeln. Kommt nichts an, prüft zuerst die Benachrichtigungs-Unit selbst:

journalctl -u "alarm@*" -n 30 --no-pager

Wollt ihr statt einer Push-Nachricht eine Mail, ersetzt den curl-Aufruf durch ein Skript, das systemctl status %i und journalctl -u %i -n 50 einsammelt und an sendmail oder msmtp übergibt. Der Mechanismus bleibt derselbe; systemd interessiert sich nicht dafür, was die Unit tut, sondern nur dafür, dass sie startet. Für Erfolgsmeldungen gibt es das Gegenstück OnSuccess=, ausgelöst beim Wechsel in den Zustand inactive.

Timer ohne Root: der Benutzerkontext

Nicht jede Aufgabe gehört ins Systemverzeichnis. Alles, was nur euer Benutzer betrifft – Mails abholen, ein Verzeichnis synchronisieren, eine Datensicherung eures Home – lässt sich im Benutzerkontext ablegen. Die Dateien liegen dann unter ~/.config/systemd/user/, und sämtliche Befehle bekommen --user und kein sudo:

mkdir -p ~/.config/systemd/user
nano ~/.config/systemd/user/backup-home.service
nano ~/.config/systemd/user/backup-home.timer
systemctl --user daemon-reload
systemctl --user enable --now backup-home.timer
systemctl --user list-timers

Zwei Anpassungen sind nötig. Erstens entfällt die Zeile User=, denn der Dienst läuft ohnehin unter euch. Zweitens lautet der Abschnitt [Install] hier WantedBy=default.target statt timers.target.

Und dann kommt die Falle, über die alle einmal stolpern: Benutzer-Units werden standardmässig beendet, sobald ihr euch abmeldet. Auf einem Server, an dem ihr euch nur zum Arbeiten anmeldet, läuft der Timer damit praktisch nie. Abhilfe schafft „Lingering", beschrieben in loginctl(1): „If enabled for a specific user, a user manager is spawned for the user at boot and kept around after logouts."

sudo loginctl enable-linger mario
loginctl user-status mario

Ersetzt den Benutzernamen. Ab jetzt startet der Benutzermanager beim Systemstart und bleibt nach dem Abmelden bestehen. Rückgängig macht das sudo loginctl disable-linger mario.

Das Journal des Benutzers lest ihr mit journalctl --user -u backup-home.service. Ohne --user sucht ihr an der falschen Stelle und findet nichts – ein Fehler, der schon manchen an seinem Verstand hat zweifeln lassen.

Ein bestehendes Backup umstellen

Der häufigste Anwendungsfall ist die Sicherung. Wer nach unserer Anleitung Linux PC lokal und auf NAS sichern mit Borg arbeitet, hat den Zeitplan bisher in der Oberfläche von Vorta hängen – was voraussetzt, dass die grafische Sitzung läuft. Ein Timer löst dieselbe Aufgabe unabhängig von Anmeldung und Desktop.

Das Vorgehen in vier Schritten: den Ablauf in ein Skript unter /usr/local/bin/ giessen und von Hand ausführen, bis er sauber durchläuft; Service- und Timer-Unit wie oben anlegen; OnFailure= eintragen und den Alarm testen; zuletzt den alten Cron-Eintrag entfernen – crontab -e für den Benutzer, sudo crontab -e für Root, dazu ein Blick in /etc/cron.d/. Wer den alten Eintrag stehen lässt, hat zwei Sicherungen, die sich um dasselbe Verzeichnis streiten.

Ein Wort zum Rückgabewert: systemd erkennt einen Fehlschlag daran, dass der Prozess mit einem Status ungleich null endet. Ein Shell-Skript, das brav exit 0 ans Ende schreibt oder dessen Fehler in einer Pipe verschwinden, meldet niemals einen Fehler – und dann nützt das schönste OnFailure= nichts. Setzt an den Anfang eures Skripts set -euo pipefail, dann bricht es bei einem Fehler ab und gibt ihn weiter.

Wenn etwas nicht klappt

Der Timer taucht in list-timers nicht auf. Entweder fehlt daemon-reload, oder der Timer ist nur gestartet und nicht aktiviert, oder im Abschnitt [Install] fehlt WantedBy=. Prüft mit systemctl is-enabled backup-home.timer.

Der Timer läuft, aber nichts passiert. Wahrscheinlich stimmt die Namenspaarung nicht. Der Timer backup-home.timer sucht backup-home.service; heisst eure Service-Datei anders, tragt Unit= im Abschnitt [Timer] ein. Die Spalte ACTIVATES in list-timers verrät, was er tatsächlich zu starten versucht.

Die Unit geht sofort in failed, Status 203/EXEC. Der Pfad in ExecStart= stimmt nicht oder die Datei ist nicht ausführbar. Absoluter Pfad ist Pflicht, und chmod +x hilft.

Status 217/USER oder 226/NAMESPACE. Der in User= angegebene Benutzer existiert nicht, oder ihm fehlt der Zugriff auf ein Verzeichnis. Prüft den Namen und die Rechte des Zielpfads.

Das Skript läuft von Hand, aber nicht als Unit. Der Klassiker. Units erben eure Shell-Umgebung nicht: kein PATH wie im Terminal, keine Variablen aus .bashrc, kein SSH-Agent, kein DISPLAY. Schreibt absolute Pfade und setzt benötigte Variablen mit Environment= oder EnvironmentFile= in der Unit.

Der Job läuft nachts nicht, weil der Rechner aus war. Dafür ist Persistent=true da. Bei einem Gerät im Ruhezustand hilft zusätzlich WakeSystem=true.

Der Benutzer-Timer läuft nur, solange ihr angemeldet seid. sudo loginctl enable-linger BENUTZER, siehe oben.

Der Alarm kommt nicht an. Prüft mit journalctl -u "alarm@*", ob die Benachrichtigungs-Unit überhaupt gestartet ist. Wurde sie gestartet und curl meldet einen Fehler, fehlt meist die Netzwerkverbindung zum Zeitpunkt des Fehlschlags oder das Thema ist falsch geschrieben. Steht in der Ausgabe gar nichts, wurde OnFailure= nicht ausgelöst – dann endet euer Skript vermutlich mit Status null, obwohl es gescheitert ist.

Fazit: Ein Job, der schweigt, ist kein Job

Der Mehraufwand gegenüber einer Cron-Zeile ist real und überschaubar: zwei Dateien statt einer Zeile, eine ungewohnte Zeitsyntax, ein Befehl zum Neuladen. Dafür bekommt ihr eine geplante Aufgabe, die sich wie jeder andere Dienst abfragen lässt, deren Ausgabe automatisch im Journal steht, die einen verpassten Termin nachholt und die euch anruft, wenn sie gescheitert ist.

Der letzte Punkt ist der einzige, auf den es wirklich ankommt. Eine Sicherung, von der ihr nicht wisst, ob sie läuft, ist keine Sicherung, sondern eine Hoffnung mit Speicherplatzbedarf. Cron kann euch das nicht sagen, weil es dafür nie gebaut wurde. Ein Timer mit OnFailure= kann es, und der Aufwand dafür beträgt sechs Zeilen.

Fangt mit dem einen Job an, dessen Ausfall euch stören würde, und stellt genau den um. Der Rest darf in Ruhe folgen – oder bei Cron bleiben. Es ist keine Glaubensfrage, sondern eine Frage danach, was passieren soll, wenn etwas schiefgeht.

Quellen und weiterführende Links

• systemd.timer(5) – Handbuchseite zu Timer-Units: OnCalendar, Persistent, RandomizedDelaySec, AccuracySec, WakeSystem, Unit
• systemd.time(7) – Kalenderausdrücke, Kurzformen und Zeitspannen
• systemd.unit(5) – OnFailure, OnSuccess und die Platzhalter %i und %n
• systemd.service(5) – Type=oneshot, ExecStart, RemainAfterExit, SuccessExitStatus
• systemd.exec(5) – Logging sowie Standard-Ein- und -Ausgabe von Units
• systemctl(1) – list-timers mit den Spalten NEXT, LEFT, LAST, PASSED, UNIT, ACTIVATES sowie daemon-reload und cat
• systemd-analyze(1) – die Unterbefehle calendar, timespan und verify
• journalctl(1) – die Optionen -u, --since, -p, -f und --user
• loginctl(1) – enable-linger, disable-linger und user-status
• ntfy: Sending messages – Aufbau des Publish-Aufrufs, Kopfzeilen Title, Priority und Tags, Hinweis zur Vertraulichkeit des Themas
• Amazon Linux 2023: Cron und systemd-Timer – Begründung für den Verzicht auf cronie
• Cronjob für Eure Nextcloud erstellen – der klassische Weg mit crontab
• Linux Problembehebung im systemd – Fehler im System mit journalctl eingrenzen
• stdout, stderr und /dev/null – warum Cron-Ausgaben so oft verschwinden
• Linux PC lokal und auf NAS sichern – Borg und Vorta als Praxisbeispiel

The post systemd-Timer statt Cronjob: einrichten und überwachen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Paperless-ngx löst genau dieses Problem, und zwar auf eurer eigenen Hardware. Die Software liest jedes eingeworfene Dokument per Texterkennung ein, legt eine durchsuchbare Archivfassung daneben, rührt das Original nicht an und macht den ganzen Bestand über eine Volltextsuche zugänglich. Kein Abo, kein fremdes Rechenzentrum, kein Anbieter, der in drei Jahren den Dienst einstellt. In dieser Anleitung richtet ihr Paperless-ngx mit Docker Compose ein, von der leeren Verzeichnisstruktur bis zum ersten gefundenen Dokument — inklusive der Stellen, an denen es erfahrungsgemäss klemmt.

Was Paperless-ngx ist, bevor ihr es einrichtet

Paperless-ngx ist ein selbst gehostetes Dokumentenverwaltungssystem unter der GPL-3.0 und laut eigener Projektbeschreibung der offizielle Nachfolger von Paperless und Paperless-ng. Das Projekt beschreibt sich selbst als „community-supported“ und hat die Verantwortung bewusst auf mehrere Personen verteilt, statt an einem einzelnen Entwickler zu hängen — ein Detail, das bei selbst gehosteter Software wichtiger ist als jede Funktionsliste. Technisch steckt Django im Rückgrat und Angular in der Oberfläche, ausgeliefert wird primär als Container.

Die Texterkennung macht Paperless nicht selbst. Dafür ist OCRmyPDF zuständig, das eine Textebene unter das gescannte Bild legt, sodass die Seite aussieht wie vorher, sich aber durchsuchen und kopieren lässt. OCRmyPDF wiederum stützt sich auf Tesseract, die freie OCR-Engine unter Apache-2.0, die aus einer Entwicklung von Hewlett-Packard zwischen 1985 und 1994 hervorgegangen ist, danach jahrelang bei Google lag und heute über hundert Sprachen erkennt. Das Ergebnis ist standardmässig ein PDF/A, also das Format, das für Langzeitarchivierung gedacht ist.

Wichtig für das Vertrauen in die Sache: Paperless speichert laut Dokumentation immer das Original und überschreibt es nie. Die Archivfassung entsteht daneben. Wenn die Texterkennung Unsinn produziert, ist das ärgerlich, aber nicht endgültig.

Version 3.0 und was sie mitbringt

Die aktuelle Hauptversion ist 3.0, veröffentlicht am 22. Juli 2026, gefolgt von den Punktständen 3.0.1 bis 3.0.3 innerhalb der darauffolgenden drei Tage — nachzulesen in der Release-Übersicht. Der Eintrag zu 3.0.0 nennt einige harte Schnitte: Die Suchmaschine Whoosh ist durch Tantivy ersetzt, die API-Version 1 ist weg, Python 3.10 wird nicht mehr unterstützt, und die Dokumentverschlüsselung wurde abgeschafft. Dazu kommen ein Plugin-Rahmen für Dokumentparser und eine Versionierung für Dokumente.

Ebenfalls neu in 3.0: eine Anbindung an Sprachmodelle unter dem Namen „Paperless AI“ und die Möglichkeit, die Texterkennung per Azure AI auszulagern. Wer eine Dokumentenverwaltung aufsetzt, um seine Steuerunterlagen aus fremden Rechenzentren herauszuholen, wird für die zweite Funktion vermutlich wenig Verwendung haben. Sie ist da; sie zu ignorieren ist eine gültige Konfigurationsentscheidung.

Was Paperless-ngx nicht ist

Es ist kein Dateisynchronisierer. Es ersetzt keine Nextcloud und will es auch nicht. Und es ist ausdrücklich keine Ablage für Dateien, die ihr weiterbearbeiten wollt — was hineingeht, ist ein abgeschlossenes Dokument: Rechnung, Vertrag, Lohnabrechnung, Arztbericht. Wer versucht, seine Projektordner darin zu verwalten, kämpft gegen das Werkzeug statt mit ihm.

Voraussetzungen: Hardware, Linux, Docker

Paperless läuft auf jedem Linux-Rechner, der dauerhaft an ist: ein alter Mini-PC, ein Heimserver, eine virtuelle Maschine, ein Raspberry Pi 4 oder 5. Die Texterkennung ist der einzige Teil, der wirklich Rechenzeit frisst, und sie läuft im Hintergrund. Ein Dokument, das drei Minuten braucht statt zwanzig Sekunden, ist beim Einlesen von zehn Seiten pro Woche kein Problem. Beim Erstimport von zwölf Jahren Aktenordnern schon — plant dafür eine Nacht ein und nicht eine Kaffeepause.

Für Arbeitsspeicher gilt: unter 2 GB wird es zäh, ab 4 GB ist es entspannt. Der Speicherplatz richtet sich nach eurem Papierberg; ein einseitiger Scan in 300 dpi landet je nach Vorlage im niedrigen einstelligen Megabyte-Bereich, und Paperless legt Original und Archivfassung ab, rechnet also grob mit dem Doppelten.

Gebraucht wird Docker samt Compose-Plugin. Wer das noch nicht installiert hat, findet den Weg dorthin in unserer Anleitung Docker Basics und Installation auf Mint, Ubuntu und Debian. Es gibt daneben einen Weg ohne Container, und die Installationsdokumentation beschreibt ihn auch: Linux zwingend, Python 3.11 bis 3.14, dazu unter anderem imagemagick, ghostscript, tesseract-ocr, ein Redis-kompatibler Broker und eine Datenbank. Diese Anleitung nimmt den Container-Weg, weil dort die Abhängigkeiten bereits stimmen und ein Update aus zwei Befehlen besteht statt aus einem Nachmittag.

Die Container und Ablagen, aus denen Paperless besteht

Bevor der erste Befehl fällt, lohnt ein Blick auf den Aufbau, denn er entscheidet später darüber, was ins Backup muss. Die empfohlene Variante mit PostgreSQL besteht laut der zugehörigen Compose-Datei aus drei Diensten: webserver mit dem Abbild ghcr.io/paperless-ngx/paperless-ngx:latest auf Port 8000, db mit postgres:18 und broker mit valkey:9-alpine, dem quelloffenen Redis-Nachfolger, der die Warteschlange der Verarbeitungsaufträge hält.

Dazu kommen vier Docker-Volumes — data, media, pgdata, redisdata — und zwei Ordner, die direkt aus eurem Dateisystem eingehängt werden: ./consume als Eingangskorb und ./export für Sicherungen. Die Trennung ist der Kern der Sache: Was ihr seht und anfasst, ist der Eingangskorb. Was das Archiv ausmacht, liegt in den Volumes.

Schritt 1: Verzeichnis anlegen und die Vorlagen holen

Legt ein eigenes Verzeichnis an, in dem alles zusammenbleibt. Alle weiteren Befehle laufen darin.

mkdir -p ~/paperless && cd ~/paperless
mkdir -p consume export

Aus dem Verzeichnis docker/compose des Projekts braucht ihr drei Dateien: eine docker-compose.*.yml passend zur gewünschten Datenbank, dazu docker-compose.env und .env. Für eine Neuinstallation empfiehlt die Dokumentation PostgreSQL.

BASE=https://raw.githubusercontent.com/paperless-ngx/paperless-ngx/main/docker/compose

wget -O docker-compose.yml  $BASE/docker-compose.postgres.yml
wget -O docker-compose.env  $BASE/docker-compose.env
wget -O .env                $BASE/.env

Die Dokumentation bietet zusätzlich ein Installationsskript an, das sich per curl holen und direkt in die Shell schütten lässt. Es funktioniert und fragt die wichtigsten Werte interaktiv ab. Wer ein Skript aus dem Netz ungelesen mit den eigenen Rechten ausführt, sollte das trotzdem bewusst tun und nicht aus Bequemlichkeit — ladet es herunter, lest es, führt es dann aus. Der manuelle Weg oben braucht drei Minuten länger und ihr wisst danach, was auf eurem Rechner steht.

Schritt 2: docker-compose.env ausfüllen

Diese Datei ist die eigentliche Konfiguration. Die Vorlage enthält die wichtigsten Werte bereits auskommentiert. Vier davon setzt ihr in jedem Fall.

Die Benutzer-ID. Der Container muss in den Eingangsordner schreiben dürfen, und zwar mit derselben Kennung wie ihr. Fragt sie ab:

id -u
id -g

Der geheime Schlüssel. PAPERLESS_SECRET_KEY ist Pflicht. Die Dokumentation ist deutlich: „Paperless will refuse to start if this is not set.“ In der Vorlage steht der Platzhalter change-me, und genau so ist er gemeint. Erzeugt einen echten Wert:

python3 -c "import secrets; print(secrets.token_urlsafe(64))"

Die Zeitzone. Ohne Angabe läuft alles in UTC, was dazu führt, dass ein Dokument vom Abend das Datum des Folgetags bekommt. Für die Schweiz also Europe/Zurich.

Die OCR-Sprache. Der Vorgabewert ist eng. Ein deutscher Mietvertrag, den Tesseract für Englisch hält, ergibt eine Textebene, die zwar existiert, aber nichts findet. Setzt PAPERLESS_OCR_LANGUAGE=deu. Zusätzliche Sprachen kommen über PAPERLESS_OCR_LANGUAGES dazu; laut Vorlage bringt das Abbild Englisch, Deutsch, Italienisch, Spanisch und Französisch bereits mit, für Deutsch ist also nichts nachzuinstallieren.

USERMAP_UID=1000
USERMAP_GID=1000
PAPERLESS_SECRET_KEY=<der erzeugte Wert>
PAPERLESS_TIME_ZONE=Europe/Zurich
PAPERLESS_OCR_LANGUAGE=deu

Ein fünfter Wert wird gebraucht, sobald Paperless nicht mehr nur lokal erreichbar ist: PAPERLESS_URL. Diese Variable setzt laut Konfigurationsdokumentation gleichzeitig ALLOWED_HOSTS, CORS_ALLOWED_HOSTS und CSRF_TRUSTED_ORIGINS. Wer sie vergisst und trotzdem einen Reverse Proxy davorstellt, bekommt beim Anmelden einen CSRF-Fehler und sucht danach an der falschen Stelle.

Schritt 3: Die Ordner in der Compose-Datei prüfen

Öffnet docker-compose.yml und seht euch den Abschnitt volumes des Dienstes webserver an. Zwei Einträge sind Pfade aus eurem Dateisystem und keine Docker-Volumes:

    volumes:
      - data:/usr/src/paperless/data
      - media:/usr/src/paperless/media
      - ./export:/usr/src/paperless/export
      - ./consume:/usr/src/paperless/consume

Wenn der Eingangskorb woanders liegen soll — etwa in einem Ordner, in den euer Scanner oder eure Nextcloud ablegt — ändert ihr hier den linken Teil vor dem Doppelpunkt. Der rechte Teil bleibt unangetastet, das ist der Pfad im Container. Der Port lässt sich im Abschnitt ports ebenfalls verschieben, falls 8000 schon belegt ist; geändert wird nur die Zahl links.

Achtet darauf, dass der Eingangsordner eurem Benutzer gehört. Ein Eingangskorb, in den der Container nicht hineinschauen darf, ist die häufigste Ursache für Dokumente, die einfach liegen bleiben und dabei keine Fehlermeldung produzieren.

Schritt 4: Starten und den ersten Benutzer anlegen

docker compose pull
docker compose up -d
docker compose logs -f webserver

Der erste Start dauert, weil Datenbankmigrationen laufen. Beobachtet das Protokoll, bis keine neuen Zeilen mehr kommen, und brecht die Anzeige dann mit Strg+C ab — das beendet nur die Protokollausgabe, nicht die Container.

Danach ist die Oberfläche unter http://127.0.0.1:8000 erreichbar, beziehungsweise unter der IP-Adresse des Servers. Beim ersten Aufruf lässt sich das Administratorkonto direkt im Browser anlegen. Falls das nicht erscheint oder ihr ein weiteres Konto braucht, geht es auch über die Kommandozeile; laut Verwaltungsdokumentation laufen alle Verwaltungsbefehle im laufenden Betrieb über docker compose exec webserver:

docker compose exec webserver createsuperuser

Schritt 5: Das erste Dokument einwerfen

Der Hauptweg in die Datenbank ist der Eingangsordner. Die Dokumentation nennt ihn beim Namen: „The primary method of getting documents into your database is by putting them in the consumption directory.“ Kopiert eine PDF-Datei nach ~/paperless/consume und schaut der Oberfläche zu. Nach einigen Sekunden bis Minuten erscheint das Dokument in der Übersicht, die Datei im Eingangsordner verschwindet, und im Archiv liegen zwei Fassungen: euer unverändertes Original und die durchsuchbare Archivfassung.

Daneben gibt es drei weitere Wege. Die Oberfläche hat einen Hochladeknopf und nimmt auch Dateien per Ziehen und Fallenlassen an. Paperless kann E-Mail-Konten abrufen und Anhänge automatisch verarbeiten. Und es erkennt Archivnummern per Strichcode, was beim Digitalisieren grosser Papierbestände hilft, wenn ihr die Blätter physisch behalten und später wiederfinden wollt.

Zwei Schalter aus der Konfiguration lohnen sich früh. PAPERLESS_CONSUMER_RECURSIVE steht auf false; auf true gesetzt schaut Paperless auch in Unterordner des Eingangskorbs. In Kombination mit PAPERLESS_CONSUMER_SUBDIRS_AS_TAGS werden diese Unterordner zu Schlagwörtern — wer ohnehin nach Ordnern sortiert scannt, bekommt damit die halbe Verschlagwortung geschenkt.

Für den Nachschub gilt: Ihr braucht einen Scanner, der brauchbare Vorlagen liefert. Wie das unter Linux ohne Herstellersoftware funktioniert, steht in Scannen unter Linux und GIMP Scan Anleitung — 300 dpi sind für Dokumente der sinnvolle Wert, mehr bringt der Texterkennung nichts und kostet nur Platz.

Ordnung, die trägt: Schlagwörter, Korrespondenten, Dokumenttypen

Paperless kennt vier Ordnungsmerkmale, und sie tun nicht dasselbe. Schlagwörter gruppieren Dokumente frei; ein Dokument kann mehrere tragen. Korrespondenten sind Person, Behörde oder Firma, von der ein Dokument stammt oder an die es ging. Dokumenttypen klassifizieren die Art: Rechnung, Brief, Kontoauszug. Speicherpfade bestimmen, wo die Datei tatsächlich abgelegt wird.

Die Versuchung, hier gleich ein dreistufiges Ordnungssystem mit 60 Schlagwörtern zu bauen, ist gross. Widersteht ihr. Die Volltextsuche findet Dokumente über ihren Inhalt, und zwar über Inhalt, Titel, Korrespondent, Typ und Schlagwörter gleichzeitig. Fünf Schlagwörter, die ihr wirklich benutzt, schlagen sechzig, die ihr beim Einlesen jedes Mal neu erwägen müsst.

Die Suche versteht dabei mehr als eine Wortliste. Laut Dokumentation funktionieren logische Ausdrücke wie shopname AND (product1 OR product2), gezielte Filter wie type:invoice tag:unpaid, Datumsbereiche in der Form created:[2005 to 2009] und Platzhalter wie produ*name. Damit findet ihr die Rechnung vom Sanitär aus dem vorletzten Winter, ohne zu wissen, wie er heisst.

Office-Dateien und E-Mails: Gotenberg und Tika

Wer nicht nur Scans, sondern auch Word-, Excel- und PowerPoint-Dateien oder deren LibreOffice-Entsprechungen ablegen will, braucht zwei zusätzliche Dienste. Die Compose-Datei docker-compose.postgres-tika.yml bringt sie mit: docker.io/gotenberg/gotenberg:8.33 für die Umwandlung und docker.io/apache/tika:latest für die Inhaltsanalyse. Angebunden werden sie über drei Variablen:

      PAPERLESS_TIKA_ENABLED: 1
      PAPERLESS_TIKA_ENDPOINT: http://tika:9998
      PAPERLESS_TIKA_GOTENBERG_ENDPOINT: http://gotenberg:3000

Gotenberg übernimmt daneben die Umwandlung von .eml-Dateien, also gespeicherten E-Mails. Wer diese Variante gleich zu Beginn nimmt, spart sich den späteren Umbau; wer nur Papier verarbeitet, lässt die beiden Container weg und spart sich rund ein Gigabyte Arbeitsspeicher.

Von aussen erreichbar? Erst lesen, dann öffnen

Hier steht eine Warnung, die aus dem Projekt selbst kommt und nicht von uns: Sensible Dokumente gehören auf einen lokalen Server, und Paperless-ngx sollte nie auf einem Rechner laufen, dem ihr nicht vertraut. Das ist kein Kleingedrucktes, sondern die Zusammenfassung dessen, was in diesem Archiv liegt — Ausweiskopien, Lohnabrechnungen, Arztberichte, Verträge. Ein kompromittierter Paperless-Server ist eine vollständige Selbstauskunft.

Daraus folgt eine klare Reihenfolge. Erste Wahl ist gar kein Zugriff von aussen: Paperless bleibt im Heimnetz, und wer von unterwegs heranwill, baut vorher einen Tunnel. Wie das geht, steht in Schnell und einfach einen Wireguard VPN betreiben. Ein VPN gibt dem Angreifer nichts, was er ohne Schlüssel überhaupt ansprechen könnte.

Wenn es doch eine öffentlich erreichbare Adresse sein muss, gehört ein Reverse Proxy mit TLS davor, und PAPERLESS_URL muss auf genau diese Adresse zeigen. Den Weg dorthin ohne Certbot beschreibt Caddy Reverse Proxy einrichten: HTTPS ohne Certbot; die Struktur ist dieselbe wie bei den dort gezeigten Diensten, nur mit Port 8000 statt 2283. Und selbst dann bleibt die Empfehlung des Projekts bestehen, dass die Maschine unter eurer Kontrolle steht.

Backup: was gesichert werden muss und was nicht reicht

Ein Dokumentenarchiv ohne Sicherung ist eine sehr aufwendige Art, Papier wegzuwerfen. Paperless bietet dafür zwei Wege, und sie schliessen sich nicht aus.

Der erste ist der Exporter. Er schreibt sämtliche Daten samt Einstellungen und Datenbankinhalt in einen Ordner — unabhängig von der Installationsart und damit auch das Mittel der Wahl, wenn ihr später von SQLite auf PostgreSQL oder von Docker auf ein anderes System wechselt.

docker compose exec webserver document_exporter ../export

Der Rückweg heisst document_importer und nimmt sowohl ein Verzeichnis als auch ein ZIP-Archiv des Exporters entgegen:

docker compose exec webserver document_importer ../export

Der zweite Weg ist die Sicherung der Docker-Volumes. Relevant sind laut Dokumentation paperless_media mit den Dokumenten, paperless_data mit Hilfsdaten und gegebenenfalls der SQLite-Datenbank sowie paperless_pgdata mit der PostgreSQL-Datenbank. Wer nur media sichert, hat am Ende die Dateien, aber keine Schlagwörter, keine Korrespondenten und keinen Suchindex — also genau den Zustand, aus dem ihr Paperless aufgesetzt habt, um herauszukommen.

Der Exportordner gehört anschliessend in eure normale Sicherungskette. Was die zu leisten hat, steht in Was ist ein gutes BackUp, und wie sich das auf einem Linux-Rechner mit Borg und einem NAS umsetzen lässt, in Linux PC lokal und auf NAS sichern. Der Exporter alleine ist keine Sicherung, solange die Ausgabe auf derselben Platte liegt wie das Original.

Aktualisieren

Die Dokumentation gibt eine feste Reihenfolge vor: keine laufenden Verarbeitungen, dann Sicherung, dann anhalten, dann aktualisieren. Migrationen laufen beim Start automatisch.

docker compose down
docker compose pull
docker compose up -d

Wenn etwas nicht klappt

Der Container startet nicht und beendet sich sofort wieder. Häufigste Ursache ist ein fehlender oder unveränderter PAPERLESS_SECRET_KEY. Paperless verweigert ohne diesen Wert den Start. Prüft die Ausgabe von docker compose logs webserver, dort steht es im Klartext.

Dokumente bleiben im Eingangsordner liegen. Fast immer sind es Berechtigungen: USERMAP_UID und USERMAP_GID stimmen nicht mit dem Besitzer des Ordners überein. Vergleicht die Ausgabe von id -u mit dem Wert in docker-compose.env und prüft mit ls -ln consume, wem der Ordner gehört.

Der Eingangsordner liegt auf einer Netzwerkfreigabe. Die Überwachung von Dateiänderungen funktioniert über Netzwerkdateisysteme nicht zuverlässig. Für diesen Fall gibt es PAPERLESS_CONSUMER_POLLING; damit fragt Paperless in einem festen Takt nach, statt sich auf Ereignisse zu verlassen.

Die Texterkennung liefert Buchstabensalat. Prüft zuerst PAPERLESS_OCR_LANGUAGE. Steht dort noch eng, erkennt Tesseract deutsche Umlaute und Wortbilder schlecht. Zweite Ursache ist die Vorlage selbst: Ein schiefer, zu dunkler oder mit 150 dpi gescannter Beleg ist auch für eine gute Engine schwer.

Nach dem Anmelden erscheint ein CSRF-Fehler. Das passiert hinter einem Reverse Proxy, wenn PAPERLESS_URL nicht gesetzt ist oder nicht exakt der aufgerufenen Adresse entspricht. Die Variable setzt ALLOWED_HOSTS und CSRF_TRUSTED_ORIGINS gleich mit; sie ist der richtige Hebel, nicht die Einzelvariablen.

Nach einem Update fehlen Funktionen oder es hakt an unerwarteter Stelle. Die Release-Notizen zu 3.0 warnen ausdrücklich vor veralteten Dateien bei Aktualisierungen ohne Container. Wer den Weg ohne Docker gewählt hat, sollte die Hinweise im jeweiligen Release lesen, statt nur die Versionsnummer zu erhöhen.

Fazit: Ein Archiv, das euch gehört, schlägt eines, das nur sucht

Der Reiz von Paperless-ngx liegt nicht in der Texterkennung. Die kann jeder Cloud-Anbieter, meistens sogar besser, weil er mehr Rechenzeit hineinsteckt und sein Modell an fremden Dokumenten trainiert hat. Der Reiz liegt darin, dass am Ende ein Verzeichnis auf einer Platte in eurer Wohnung steht, in dem eure Originale unverändert liegen, daneben eine durchsuchbare Fassung in einem Archivformat, und dass ihr beides mit einem einzigen Befehl exportieren und woandershin mitnehmen könnt.

Das ist der Unterschied zwischen einem Werkzeug und einem Dienst. Ein Dienst funktioniert, solange jemand anderes will, dass er funktioniert — und die Preisliste, die Nutzungsbedingungen und die Frage, wer beim Anbieter in eure Steuerunterlagen sehen darf, ändern sich ohne euch. Ein Werkzeug funktioniert, solange ihr es pflegt. Der Aufwand dafür ist die Konfigurationsdatei oben, ein Update alle paar Wochen und eine Sicherung, die tatsächlich läuft. Das ist mehr als null, und es ist deutlich weniger als ein Abo, das ihr nicht kündigen könnt, ohne den Zugriff auf zwölf Jahre Papier zu verlieren.

Fangt klein an: ein Ordner, ein Korrespondent, fünf Schlagwörter. Der Rest kommt beim Benutzen. Der Aktenordner mit der Aufschrift „Wichtig“ darf bleiben, wo er ist — ihr müsst ihn nur nicht mehr aufmachen.

Quellen und weiterführende Links

• paperless-ngx auf GitHub — Projektbeschreibung, Lizenz GPL-3.0, Sicherheitshinweis zum Betrieb
• docs/setup.md — Installation mit Docker Compose und Voraussetzungen für den Weg ohne Container
• docs/configuration.md — sämtliche Umgebungsvariablen mit Vorgabewerten
• docs/administration.md — Exporter, Importer, Verwaltungsbefehle und Update-Reihenfolge
• docs/usage.md — Eingangsordner, Schlagwörter, Korrespondenten, Suchsyntax
• docker-compose.postgres.yml — die drei Dienste, ihre Abbilder und die Volumes
• docker-compose.postgres-tika.yml — Gotenberg und Tika für Office-Dateien und E-Mails
• docker-compose.env — die Vorlage mit Benutzer-ID, Schlüssel, Zeitzone und OCR-Sprachen
• Release-Übersicht und Release-Notizen zu 3.0.0
• OCRmyPDF — die Textebene unter dem Scan, PDF/A als Vorgabe, Lizenz MPL-2.0
• Tesseract — die OCR-Engine dahinter, Apache-2.0, über hundert Sprachen
• Eigene Anleitungen: Docker Basics, Caddy Reverse Proxy, Wireguard VPN, Scannen unter Linux, Was ist ein gutes BackUp, Linux PC lokal und auf NAS sichern

The post Paperless-ngx einrichten: papierlos ohne Cloud appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Der Unterschied zu einem gewöhnlichen Proxy liegt in der Richtung. Ein normaler Proxy steht vor euch und schützt euch gegenüber dem Server. Ein Reverse Proxy steht vor den Servern und nimmt ihnen die Aussenwelt ab. Für den Browser existiert nur eine einzige Adresse, ein einziges Zertifikat, ein einziger Einstiegspunkt. Was dahinter läuft, auf welchem Port, in welchem Container, auf welchem Rechner im lokalen Netz — davon bekommt der Client nichts mit.

Der naheliegende Gegenvorschlag lautet: einfach jedem Dienst einen eigenen Port geben und die Sache über example.ch:8080 ansprechen. Das funktioniert, bis ihr das erste Mal aus einem fremden WLAN, einem Firmennetz oder einem Hotelnetzwerk zugreifen wollt. Dort ist alles ausser 80 und 443 üblicherweise dicht. Dazu kommt, dass jedes dieser Ziele ein eigenes gültiges Zertifikat braucht und jeder Dienst seine TLS-Konfiguration selbst pflegen müsste — mit dem Ergebnis, dass drei Programme drei verschiedene Meinungen darüber haben, welche Cipher noch in Ordnung sind.

Genau an dieser Stelle setzt dieser Artikel an: eine vollständige Einrichtung von Caddy als Reverse Proxy unter Debian und Ubuntu, von der Installation über die erste Caddyfile bis zu Wildcard-Zertifikaten per DNS-Challenge. Wer bisher mit Apache und Certbot gearbeitet hat, findet den vertrauten Weg in unserer Anleitung zum SSL-Zertifikat für den Nextcloud-Homeserver. Hier geht es um den Weg, bei dem dieser Schritt schlicht entfällt.

Warum Caddy und nicht nginx

Caddy ist ein in Go geschriebener Webserver, der unter der Apache-2.0-Lizenz steht und ohne externe Abhängigkeiten auskommt. Die aktuelle stabile Version ist v2.11.4 vom 3. Juni 2026. Das Alleinstellungsmerkmal steht im Untertitel des Projekts und ist keine Marketingfloskel: automatisches HTTPS, und zwar als Standardverhalten, nicht als Zusatzpaket.

Automatisches HTTPS ist eingebaut, nicht angeflanscht

Bei nginx oder Apache läuft die Zertifikatsbeschaffung über ein zweites Programm. Certbot legt Dateien ab, schreibt in die Konfiguration hinein, richtet einen Timer ein und startet den Webserver neu. Vier bewegliche Teile, die alle einzeln kaputtgehen können. Caddy spricht ACME selbst. Es erkennt aus der Konfiguration, für welche Hostnamen es Zertifikate braucht, holt sie, erneuert sie und leitet HTTP auf HTTPS um — ohne dass ihr das irgendwo hinschreibt.

Wie gross der Unterschied im Alltag ist, zeigt das Projekt Immich selbst. In der offiziellen Reverse-Proxy-Dokumentation steht eine nginx-Konfiguration mit erhöhtem Upload-Limit, abgeschaltetem Request-Buffering, gesetzten Weiterleitungs-Headern und Timeouts von 600 Sekunden. Direkt darunter steht die Caddy-Variante, vollständig:

immich.example.org {
    reverse_proxy http://127.0.0.1:2283
}

Das ist kein verkürztes Beispiel. Die drei Dinge, die nginx dort von Hand braucht, sind in Caddy Standard. Das Upload-Limit: nginx begrenzt den Request-Body per Vorgabe auf 1 MB und antwortet darüber mit einem 413, was bei Foto- und Video-Uploads sofort auffällt. Caddy kennt kein solches Vorgabelimit, die Direktive request_body müsst ihr setzen, wenn ihr begrenzen wollt. Die Weiterleitungs-Header: Caddy setzt X-Forwarded-For, X-Forwarded-Proto und X-Forwarded-Host von sich aus und verwirft eingehende Werte dieser Felder, damit sie nicht gefälscht werden können. Und WebSockets laufen einfach durch, ohne die aus nginx bekannte Upgrade-Klausel.

Wo Caddy nginx nicht ersetzt

Ehrlichkeitshalber gehört die Gegenrichtung dazu. nginx hat ein deutlich grösseres Ökosystem an Modulen, mehr Feinsteuerung beim Caching und mehr Personen, die sich damit auskennen. Wer bereits eine gewachsene, funktionierende nginx-Konfiguration hat, gewinnt durch einen Wechsel wenig. Und Caddy hat eine architektonische Eigenheit, die überrascht: Erweiterungen sind einkompilierte Go-Module. Ein Plugin nachzurüsten bedeutet, das Binary neu zu bauen. Dafür gibt es einen bequemen Befehl, aber es bleibt ein anderes Modell als eine nachinstallierte .so-Datei — mit einer Nebenwirkung, auf die wir weiter unten zurückkommen.

Voraussetzungen für den Reverse Proxy

Vier Dinge müssen stimmen, bevor die erste Zeile Konfiguration Sinn ergibt.

• Ein Server mit Debian 12/13 oder Ubuntu 24.04 und Root- beziehungsweise sudo-Rechten. Ein Raspberry Pi reicht für den Heimgebrauch vollkommen aus, der Proxy selbst ist genügsam.
• Eine Domain, deren DNS-Einträge auf eure öffentliche IP zeigen. Bei wechselnder IP am Hausanschluss braucht es dafür einen dynamischen Eintrag, wie in unserer Anleitung zum DynDNS-Eintrag bei dynamischer IP beschrieben. Für jeden Dienst legt ihr eine eigene Subdomain an.
• Die Ports 80 und 443 müssen von aussen auf den Proxy zeigen. Wie das am Schweizer Router eingerichtet wird, steht in unserem Beitrag zur Portweiterleitung auf Swisscom- und UPC-Modems. Hängt ihr an einem DS-Lite-Anschluss ohne öffentliche IPv4-Adresse, hilft keine Weiterleitung — dann führt der Weg über einen VPS als Brücke, wie in Webdienste hinter DS-Lite verfügbar machen mit Wireguard gezeigt.
• Die Dienste laufen bereits und lauschen lokal. Ob nativ installiert oder über Docker, spielt keine Rolle. Wichtig ist, dass sie auf 127.0.0.1 gebunden sind und nicht auf 0.0.0.0 — sonst ist der Proxy umgehbar.

Läuft auf dem Rechner bereits ein Apache oder nginx auf Port 80 und 443, stoppt und deaktiviert ihn vorher. Zwei Programme auf demselben Port ergeben beim Start nur eine Fehlermeldung.

Caddy unter Debian und Ubuntu installieren

Die Distributionspakete hinken der Entwicklung meist hinterher. Nehmt deshalb das offizielle Repository des Projekts:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg
sudo chmod o+r /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

Das Paket bringt eine systemd-Unit mit und startet den Dienst sofort. Prüft danach die Version:

caddy version
systemctl status caddy

Ruft ihr jetzt die IP des Servers im Browser auf, begrüsst euch eine Startseite. Der Dienst läuft unter dem Benutzer caddy, die Konfiguration liegt in /etc/caddy/Caddyfile, und die Zertifikate landen später unter /var/lib/caddy/.local/share/caddy. Diese drei Pfade solltet ihr euch merken, sie beantworten später die meisten Fragen.

Die erste Caddyfile: ein Dienst, ein Zertifikat

Öffnet /etc/caddy/Caddyfile, löscht den mitgelieferten Inhalt und schreibt stattdessen:

{
	email admin@example.ch
}

cloud.example.ch {
	reverse_proxy 127.0.0.1:8080
}

Das war die vollständige Konfiguration für einen Dienst mit gültigem Zertifikat und automatischer Weiterleitung von HTTP auf HTTPS. Der geschweifte Block ganz oben ist der globale Optionsblock. Er muss der erste Block der Datei sein und darf nur einmal vorkommen. Die Adresse unter email wird für das ACME-Konto verwendet; darüber informiert euch die Zertifizierungsstelle, wenn eine Erneuerung dauerhaft scheitert. Der zweite Block ist ein Site-Block: alles zwischen den Klammern gilt für Anfragen an diesen Hostnamen.

Formatiert und prüft die Datei, bevor ihr sie aktiviert:

sudo caddy fmt --overwrite /etc/caddy/Caddyfile
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

Ein Hinweis zur Einrückung: Die Caddyfile erwartet Tabulatoren, keine Leerzeichen. caddy fmt --overwrite räumt das für euch auf, weshalb dieser Befehl der erste von dreien ist. Alle Unterbefehle sind dokumentiert, im Alltag braucht ihr vor allem diese drei.

Was beim ersten Neuladen tatsächlich passiert

Caddy liest aus dem Site-Block heraus, dass es ein Zertifikat für cloud.example.ch braucht, und beginnt sofort damit. Primäre Zertifizierungsstelle ist Let's Encrypt, bei Fehlern weicht Caddy automatisch auf ZeroSSL aus. Zur Validierung stehen die HTTP-Challenge über Port 80 und die TLS-ALPN-Challenge über Port 443 bereit; Caddy wählt zunächst zufällig und merkt sich, welcher Weg bei euch verlässlich funktioniert. Nach wenigen Sekunden ist das Zertifikat da und der Dienst über HTTPS erreichbar.

Zusehen könnt ihr dabei im Journal:

journalctl -u caddy -f

Und hier lauert die erste ernsthafte Falle. Solange die DNS-Einträge noch nicht stimmen oder die Portweiterleitung fehlt, scheitert die Validierung — und Let's Encrypt zählt mit. Nach den offiziellen Rate Limits sind pro Bezeichner und Konto fünf fehlgeschlagene Autorisierungen pro Stunde erlaubt, pro registrierter Domain 50 Zertifikate in sieben Tagen und für einen exakt gleichen Satz von Bezeichnern fünf Zertifikate in sieben Tagen. Wer eine Konfiguration in Ruhe durchprobieren will, schaltet deshalb vorher auf die Testumgebung um:

{
	email admin@example.ch
	acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
}

Die Zertifikate der Testumgebung sind im Browser ungültig, das ist beabsichtigt. Wenn alles steht, nehmt ihr die Zeile wieder heraus und ladet neu. Praktisch heisst das: erst mit Staging bauen, dann scharf schalten. Wer diese zwei Minuten überspringt, sitzt im schlechtesten Fall eine Woche auf einem gesperrten Bezeichner.

Drei Dienste hinter einer Adresse

Der eigentliche Gewinn zeigt sich erst ab dem zweiten Dienst. Jeder bekommt seinen eigenen Site-Block, jeder sein eigenes Zertifikat, alle teilen sich denselben Port:

{
	email admin@example.ch
}

cloud.example.ch {
	reverse_proxy 127.0.0.1:8080
}

vault.example.ch {
	reverse_proxy 127.0.0.1:8000
}

fotos.example.ch {
	reverse_proxy 127.0.0.1:2283
}

Die Ports sind die Vorgaben der jeweiligen Projekte: 8000 für Vaultwarden, 2283 für Immich, 8080 für einen Nextcloud-Container hinter dem Proxy. Bemerkenswert ist vor allem, was hier nicht steht. Keine Upload-Grenze für Immich. Keine WebSocket-Klausel für Vaultwarden, dessen eigenes Caddy-Beispiel im Projekt-Wiki ebenfalls mit einer einzigen reverse_proxy-Zeile auskommt. Keine Zertifikatspfade, keine Cipher-Listen, kein Redirect-Block.

Liegt ein Dienst auf einem anderen Rechner im lokalen Netz, tragt ihr dort statt 127.0.0.1 dessen IP ein. Und wenn das Backend selbst schon HTTPS spricht, etwa mit einem selbstsignierten Zertifikat, sieht das so aus:

nas.example.ch {
	reverse_proxy https://192.168.1.50:5001 {
		transport http {
			tls_insecure_skip_verify
		}
	}
}

Das Überspringen der Zertifikatsprüfung ist hier vertretbar, weil die Strecke im eigenen Netz liegt und die Verschlüsselung nach aussen der Proxy übernimmt. Auf einer Verbindung über das Internet wäre es ein Fehler.

Nextcloud hinter dem Reverse Proxy richtig konfigurieren

Nextcloud ist der Dienst, bei dem am häufigsten etwas schiefgeht — nicht wegen Caddy, sondern weil Nextcloud sich selbst hinter einem Proxy falsch einschätzt. Es sieht eine unverschlüsselte Anfrage von 127.0.0.1 und baut daraus Links mit http://. Ergebnis: Anmeldeschleifen, kaputte Vorschaubilder, und im Log steht bei jedem Zugriff dieselbe IP-Adresse. Ergänzt deshalb in config/config.php:

'trusted_domains' => [
  'cloud.example.ch',
],
'trusted_proxies' => ['127.0.0.1'],
'forwarded_for_headers' => ['HTTP_X_FORWARDED_FOR'],
'overwriteprotocol' => 'https',
'overwritehost' => 'cloud.example.ch',
'overwrite.cli.url' => 'https://cloud.example.ch',

Die Bedeutung der Werte steht in der kommentierten Beispielkonfiguration im Nextcloud-Repository. trusted_proxies erlaubt Nextcloud, den weitergereichten Client-IPs überhaupt zu glauben, forwarded_for_headers legt fest, welchem Header dabei vertraut wird, und die drei overwrite-Werte korrigieren die Selbsteinschätzung bei der URL-Erzeugung. Läuft Nextcloud in einem Container, gehört unter trusted_proxies nicht 127.0.0.1, sondern die Adresse des Docker-Netzes.

Sicherheitskopfzeilen an einer Stelle statt in jedem Dienst

Der zweite grosse Vorteil eines zentralen Einstiegspunkts: Kopfzeilen, die für alle Dienste gelten sollen, schreibt ihr genau einmal. Caddy kennt dafür wiederverwendbare Bausteine, sogenannte Snippets, die in runden Klammern definiert und mit import eingebunden werden:

{
	header {
		Strict-Transport-Security "max-age=31536000"
		X-Content-Type-Options "nosniff"
		X-Frame-Options "SAMEORIGIN"
		Referrer-Policy "no-referrer"
		-Server
	}
}

cloud.example.ch {
	import sicherheit
	reverse_proxy 127.0.0.1:8080
}

vault.example.ch {
	import sicherheit
	reverse_proxy 127.0.0.1:8000
}

Das führende Minus vor Server löscht die Kopfzeile aus der Antwort. Bei Strict-Transport-Security ist Vorsicht angebracht: Die Anweisung sagt jedem Browser, diese Domain für die angegebene Dauer ausschliesslich über HTTPS anzusprechen — hier ein Jahr. Das ist erwünscht, aber es lässt sich nicht kurzfristig zurücknehmen. Nehmt die Zusätze includeSubDomains und preload erst dazu, wenn wirklich jede Subdomain dauerhaft per HTTPS erreichbar ist.

Zertifikate ohne offene Ports: die DNS-Challenge

HTTP- und TLS-ALPN-Challenge setzen voraus, dass die Zertifizierungsstelle euren Server von aussen erreicht. Das ist nicht immer der Fall: an einem DS-Lite-Anschluss fehlt die öffentliche IPv4-Adresse, manche Provider sperren Port 80, und für Dienste, die absichtlich nur im VPN erreichbar sind, gibt es gar keinen Weg von aussen. Ausserdem lassen sich Wildcard-Zertifikate ausschliesslich per DNS ausstellen.

Die DNS-Challenge dreht die Beweisrichtung um: Statt einer Datei auf eurem Server legt Caddy einen TXT-Eintrag in eurer DNS-Zone an. Damit braucht es keinen einzigen offenen Port — aber Schreibzugriff auf die Zone.

Plugin nachrüsten mit caddy add-package

Für jeden DNS-Anbieter gibt es ein eigenes Modul, und weil Caddy-Erweiterungen einkompiliert werden, braucht es ein neues Binary. Der eingebaute Befehl erledigt das:

sudo caddy add-package github.com/caddy-dns/cloudflare
caddy list-modules --packages | grep cloudflare
sudo systemctl restart caddy

Und damit zur angekündigten Nebenwirkung: caddy add-package ersetzt das vom Paketmanager installierte Binary. Beim nächsten apt upgrade überschreibt apt es wieder mit der Standardversion — das Plugin ist weg, die Caddyfile verweist auf ein Modul, das es nicht mehr gibt, und der Dienst startet nicht. Wer das vermeiden will, führt add-package nach jedem Upgrade erneut aus oder aktualisiert stattdessen mit caddy upgrade, das die installierten Module beibehält. Notiert euch die Zeile mit euren Paketen an einer Stelle, an der ihr sie wiederfindet.

Den API-Token sauber übergeben

Der Token gehört nicht in die Caddyfile, sondern in die Umgebung des Dienstes. Bei Cloudflare braucht er laut Modul-Dokumentation genau zwei Berechtigungen: Zone.Zone:Read und Zone.DNS:Edit, beschränkt auf die betroffenen Zonen. Legt ein systemd-Override an:

sudo systemctl edit caddy

Und tragt dort ein:

[Service]
Environment="CF_API_TOKEN=euer_token_hier"

In der Caddyfile wird der Wert dann als Platzhalter referenziert:

intern.example.ch {
	tls {
		dns cloudflare {env.CF_API_TOKEN}
	}
	reverse_proxy 127.0.0.1:3000
}

Die ältere Schreibweise mit getrennten zone_token- und api_token-Feldern taucht in vielen Anleitungen im Netz noch auf. Das Modul bezeichnet sie ausdrücklich als veraltet und behält sie nur aus Kompatibilitätsgründen — nehmt die einzeilige Variante.

Wildcard-Zertifikate

Steht die DNS-Challenge, könnt ihr ein einziges Zertifikat für alle Subdomains ausstellen lassen. Das reduziert die Zahl der ACME-Anfragen erheblich und hält euch von den Rate Limits fern:

*.example.ch {
	tls {
		dns cloudflare {env.CF_API_TOKEN}
	}

	@cloud host cloud.example.ch
	handle @cloud {
		reverse_proxy 127.0.0.1:8080
	}

	@vault host vault.example.ch
	handle @vault {
		reverse_proxy 127.0.0.1:8000
	}

	handle {
		abort
	}
}

Die mit @ beginnenden Ausdrücke sind Matcher, die den passenden Hostnamen herausgreifen. Der letzte handle-Block ohne Matcher fängt alles ab, was zu keinem Dienst gehört, und bricht die Verbindung ab — sonst würde jede erfundene Subdomain irgendwo landen. Beachtet dabei, dass ein Wildcard-Zertifikat nur eine Ebene abdeckt: *.example.ch gilt für cloud.example.ch, aber nicht für a.b.example.ch.

Betrieb: prüfen, neu laden, Logs lesen

Im laufenden Betrieb sind es vor allem drei Handgriffe. Nach jeder Änderung an der Caddyfile gilt dieselbe Reihenfolge wie oben: formatieren, validieren, neu laden. systemctl reload caddy übernimmt die neue Konfiguration ohne Verbindungsabbruch — ein restart ist nur nötig, wenn ihr das Binary getauscht oder die systemd-Unit geändert habt.

Standardmässig landet alles im Journal. Für einen einzelnen Dienst lohnt sich ein eigenes Zugriffsprotokoll, etwa um es später an CrowdSec zu übergeben:

cloud.example.ch {
	log {
		output file /var/log/caddy/cloud.log {
			roll_size 10MiB
			roll_keep 5
		}
	}
	reverse_proxy 127.0.0.1:8080
}

Das Verzeichnis muss dem Benutzer caddy gehören. Und ein Punkt, der gern vergessen wird: In eure Sicherung gehört nicht nur /etc/caddy, sondern auch /var/lib/caddy/.local/share/caddy. Dort liegen die Zertifikate, die privaten Schlüssel und der ACME-Kontoschlüssel. Ohne dieses Verzeichnis holt ein neu aufgesetzter Server zwar alle Zertifikate neu — aber jeder solche Durchlauf zählt auf die Rate Limits.

Stolperfallen, die euch einen Abend kosten

• Port 80 zugemacht. Viele schliessen ihn, weil ohnehin alles über HTTPS läuft. Dann fehlt die Weiterleitung für Besucher, die ohne Präfix tippen, und die HTTP-Challenge fällt als Ausweichweg weg. Lasst ihn offen, ausser ihr nutzt ausschliesslich die DNS-Challenge.
• Alter Webserver läuft noch. Ein address already in use im Journal bedeutet fast immer einen vergessenen Apache oder nginx.
• Dienst lauscht auf 0.0.0.0. Dann ist er direkt über seinen Port erreichbar, unverschlüsselt und ohne die gesetzten Kopfzeilen. Bindet Backends an 127.0.0.1 und blockt die Ports zusätzlich in der Firewall.
• Cloudflare-Proxy davor. Steht in eurem DNS die orange Wolke, terminiert Cloudflare TLS selbst und die TLS-ALPN-Challenge scheitert zwangsläufig. Dann führt der Weg über die DNS-Challenge.
• Konfiguration nicht validiert. systemctl reload mit einer fehlerhaften Datei lässt die alte Konfiguration aktiv und meldet den Fehler nur im Journal. Wer nicht hinsieht, wundert sich, warum die Änderung nichts bewirkt.
• Leerzeichen statt Tabulatoren. Erzeugt Fehlermeldungen, die auf den ersten Blick nichts mit Einrückung zu tun haben. caddy fmt --overwrite zuerst.

Was ihr tun könnt

• Legt für jeden Dienst eine eigene Subdomain an, statt Ports nach aussen zu öffnen. Das kostet nichts und ist die Grundlage für alles Weitere.
• Baut die erste Konfiguration gegen den Staging-Endpunkt von Let's Encrypt. Zwei zusätzliche Minuten, die euch im Fehlerfall eine Woche Wartezeit ersparen.
• Bindet alle Backends auf 127.0.0.1 und prüft mit ss -tlnp, ob sich noch etwas an einer öffentlichen Adresse festhält.
• Zieht die Sicherheitskopfzeilen in ein Snippet und importiert es in jeden Site-Block, statt sie in jedem Dienst einzeln zu pflegen.
• Nehmt /var/lib/caddy/.local/share/caddy in die Sicherung auf.
• Wenn ihr Plugins nachrüstet: haltet die add-package-Zeile fest und prüft nach jedem Systemupdate mit caddy list-modules --packages, ob sie noch da sind.

Fazit: Caddy macht TLS zur Standardeinstellung statt zur Bastelaufgabe

Die verbreitete Kombination aus nginx und Certbot funktioniert seit Jahren zuverlässig, und niemand muss sie ersetzen. Aber sie besteht aus vier Teilen, die zusammenarbeiten müssen: Webserver, ACME-Client, Timer und Konfigurationsdateien, die zwei Programme gleichzeitig bearbeiten. Jeder dieser Teile hat schon einmal jemandem ein abgelaufenes Zertifikat beschert.

Caddy schneidet diese Kette auf ein Teil zusammen. Sechs Zeilen Konfiguration reichen für einen Dienst mit gültigem Zertifikat, automatischer Erneuerung, HTTP-Weiterleitung, HTTP/2, HTTP/3 und funktionierenden WebSockets. Dass Immich in der eigenen Dokumentation eine halbe Seite nginx neben drei Zeilen Caddy stellt, ist keine Werbung des Caddy-Projekts, sondern die Einschätzung eines unbeteiligten Dritten.

Der Preis dafür sind weniger Stellschrauben und ein Erweiterungsmodell, das bei jedem Systemupdate Aufmerksamkeit verlangt. Für die überwiegende Mehrheit selbst gehosteter Installationen ist das ein guter Handel. Verschlüsselung sollte der unauffällige Normalzustand sein und nicht die Aufgabe, die dreimal im Jahr um drei Uhr morgens Alarm schlägt — und genau daran gemessen ist Caddy für Selfhoster derzeit die vernünftigste Wahl.

Quellen und weiterführende Links

• Caddy Documentation — Install, offizielle Installationswege inklusive apt-Repository
• Caddy Documentation — Automatic HTTPS, Ablauf der Zertifikatsbeschaffung und Challenge-Auswahl
• Caddy Documentation — reverse_proxy, Syntax, gesetzte Header, Transport und Lastverteilung
• Caddy Documentation — tls, DNS-Challenge, Propagation und alternative Zertifizierungsstellen
• Caddy Documentation — Global Options, globaler Optionsblock mit email und acme_ca
• Caddy Documentation — Command Line, validate, fmt, reload, add-package und upgrade
• Caddy Documentation — Keeping Caddy Running, systemd-Dienst, Benutzer und Datenverzeichnisse
• Caddy Documentation — request_body, Begrenzung der Anfragegrösse
• caddyserver/caddy — Releases, Versionsstand v2.11.4 vom 3. Juni 2026
• caddy-dns/cloudflare, Konfigurationssyntax und benötigte Token-Berechtigungen
• Let's Encrypt — Rate Limits, verbindliche Grenzwerte für Ausstellung und Fehlversuche
• nginx — client_max_body_size, Vorgabewert 1 MB und Verhalten bei Überschreitung
• Immich — Reverse Proxy, Vergleich der nginx- und Caddy-Konfiguration
• Vaultwarden Wiki — Proxy examples, Caddy-Beispiel des Projekts
• Nextcloud — config.sample.php, kommentierte Referenz zu trusted_proxies und den overwrite-Werten

The post Caddy Reverse Proxy einrichten: HTTPS ohne Certbot appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Die gute Nachricht: Linux bietet mit Swap und zRAM sehr effektive Werkzeuge, um genau solche Situationen deutlich zu entschärfen. Richtig eingerichtet sorgen sie dafür, dass das System stabil bleibt, weniger einfriert und sich insgesamt flüssiger anfühlt – selbst bei knappen RAM-Ressourcen.

Dieses Tutorial erklärt:

• was Swap und zRAM sind
• worin der Unterschied liegt
• warum die Kombination sinnvoll ist
• wie man beides korrekt einrichtet
• wie man überprüft, ob alles richtig funktioniert

Das Ganze ist bewusst einsteigerfreundlich, aber technisch korrekt gehalten.

Was ist Swap

Swap ist Auslagerungsspeicher. Wenn der physische Arbeitsspeicher (RAM) knapp wird, kann Linux Speicherbereiche auf ein langsameres Medium auslagern – meist eine SSD oder HDD.

Vorteile von Swap

• verhindert Abstürze durch Speichermangel (OOM-Killer)
• sorgt dafür, dass das System weiterläuft
• ideal als Sicherheitsnetz

Nachteile von Swap

• deutlich langsamer als RAM
• kann bei starker Nutzung zu Rucklern führen

Swap ist wichtig, aber allein nicht optimal für Performance.

Was ist zRAM

zRAM ist komprimierter Arbeitsspeicher.

Dabei wird ein Teil des RAMs als komprimiertes Blockgerät genutzt. Daten werden also nicht auf die Festplatte, sondern komprimiert im RAM selbst abgelegt.

Vorteile von zRAM

• extrem schnell (bleibt im RAM)
• sehr gut komprimierbar (oft 1.5–2.5×)
• ideal für inaktive Speicherbereiche
• reduziert SSD-Swap massiv

Nachteile von zRAM

• benötigt etwas CPU-Leistung
• kann keinen echten RAM ersetzen

zRAM ist kein Ersatz für RAM, aber ein sehr effizienter Puffer.

Warum Swap UND zRAM kombinieren

Die beste Lösung ist eine zweistufige Speicherstrategie:

1. zRAM als schneller, komprimierter Zwischenspeicher
2. klassischer Swap als Notfallreserve

Linux nutzt automatisch zuerst den Swap mit der höheren Priorität – also zRAM – und greift nur im Ernstfall auf die SSD zurück.

Ergebnis:

• weniger Freezes
• stabileres Multitasking
• deutlich bessere Reaktionsfähigkeit

Schritt 1: Vorhandenen Swap prüfen

swapon --show

oder:

free -h

Wenn kein Swap vorhanden ist oder ihr neu starten wollt, geht es weiter mit Schritt 2. Solltet ihr bereits eine Swap Partition haben, überspringt Schritt 2, und macht weiter mit Schritt 3.

Schritt 2: Swapfile anlegen (Beispiel: 4 GB)

Gebt diese Befehle einzeln in die Konsole ein:

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Danach dauerhaft aktivieren in der fstab Datei:

sudo nano /etc/fstab

Eintrag hinzufügen:

/swapfile none swap sw 0 0

Speichern mit strg+o und beenden mit strg-x

Schritt 3: zRAM installieren

Unter Ubuntu, KDE Neon und ähnlichen Debian Systemen:

sudo apt install zram-tools

Konfiguration öffnen:

sudo nano /etc/default/zramswap

Empfohlene Grundeinstellung am Ende der Datei setzen:

ENABLED=true
PERCENT=40
PRIORITY=100

Erklärung:

• PERCENT=40 → 40 % des RAMs als zRAM
• PRIORITY=100 → zRAM wird vor dem Swap genutzt

Dienst neu starten:

sudo systemctl restart zramswap

Schritt 4: Swappiness sinnvoll setzen

Swappiness steuert, wie früh Linux Swap nutzt, sollte der Arbeitspeicher eine bestimmte Auslastung erreichen.

Empfehlung für Desktop + wenig RAM:

sudo sysctl vm.swappiness=80

Dauerhaft:

sudo nano /etc/sysctl.conf

Eintrag:

vm.swappiness=80

Danach die Einstellungen mit:

sudo sysctl -p

direkt aktivieren

Schritt 5: Überprüfen, ob alles korrekt läuft

Swap-Status anzeigen

swapon --show

Erwartetes Ergebnis:

• zRAM mit hoher Priorität
• Swapfile mit niedriger Priorität

/dev/zram0

• 6 GB zRAM → passt zu PERCENT=40
• PRIO 100 → wird immer zuerst benutzt
• USED 0B → aktuell genug RAM, kein Druck

/swapfile

• 4 GB SSD-Swap
• PRIO -2 → klassischer Fallback
• wird erst benutzt, wenn zRAM voll ist

Genau die richtige Reihenfolge, die Einstellungen sind korrekt gesetzt.

Speicherverhalten beobachten

free -h

oder live:

watch -n 1 swapon --show

Gesundes Verhalten:

• zRAM wird genutzt
• SSD-Swap bleibt möglichst leer
• System bleibt bedienbar

Typische Empfehlungen nach RAM-Größe

4–8 GB RAM

• zRAM: 50 %
• Swapfile: 2–4 GB

16 GB RAM

• zRAM: 30–40 %
• Swapfile: 4–8 GB

32 GB RAM

• zRAM: optional
• Swapfile: klein oder nur als Fallback

Fazit

Swap und zRAM sind keine Notlösungen, sondern bewusst entwickelte Werkzeuge im Linux-Kernel.

Richtig kombiniert sorgen sie für:

• mehr Stabilität
• weniger Einfrieren
• bessere Alltagstauglichkeit

Gerade auf Systemen mit wenig RAM ist diese Konfiguration oft der größte Performance-Gewinn ohne neue Hardware.

Wenn trotz zRAM und Swap dauerhaft alles ausgelastet ist, gilt trotzdem: Kein Tuning ersetzt fehlenden Arbeitsspeicher. Aber bis zu diesem Punkt holt diese Methode das Maximum aus eurem System heraus.

The post Mehr Leistung bei wenig RAM: Swap & zRAM unter Linux appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

In diesem Tutorial lernt ihr, wie man Tor auf Ubuntu, Linux Mint und Debian installiert und wie man Telegram Desktop über das Tor-Netzwerk verwendet, um eure Privatsphäre zusätzlich zu schützen. Mit dieser Konfiguration könnt ihr Nachrichten verschicken, ohne dass eure IP-Adresse direkt offengelegt wird. Dies bietet zusätzlichen Schutz vor Überwachung und möglichen Angriffen auf eure Daten.

Vorteile der Nutzung von Tor

• Anonymität: Eure IP-Adresse wird verschleiert, sodass ihr im Internet verborgener bleibt.
• Sicherheit: Da euer Datenverkehr verschlüsselt durch verschiedene Knotenpunkte geleitet wird, wird es extrem schwierig, euch zu verfolgen.
• Zensur umgehen: Tor ermöglicht es euch, auf Inhalte zuzugreifen, die in einem Land möglicherweise zensiert oder blockiert sind.

Lasst uns jetzt damit beginnen, Tor zu installieren und für Telegram Desktop zu konfigurieren.

Tor auf Ubuntu, Mint und Debian installieren

Tor kann in allen drei Linux-Distributionen (Ubuntu, Linux Mint und Debian) über die offiziellen Repositories installiert werden.

Schritt 1: System aktualisieren

Bevor ihr mit der Installation beginnt, stelle sicher, dass euer System auf dem neuesten Stand ist. Öffnet das die Konsole, auch Terminal genannt. Gebt folgenden Befehl ein:

sudo apt update && sudo apt upgrade

Schritt 2: Das Tor-Repository hinzufügen (optional)

Falls ihr die neuste Tor Version wollt, müsst ihr das offizielle Tor-Repository hinzufügen. Wer sich mit einer älteren Version zufrieden gibt, überspringt den Punkt, und geht gleich zu Schritt 3.

• Öffnet das Terminal und fügt den GPG-Schlüssel für das Tor-Repository hinzu:

sudo apt install gnupg2

curl https://deb.torproject.org/torproject.org/keys/archivist.gpg | sudo gpg --dearmor -o /usr/share/keyrings/tor-archive-keyring.gpg

Füge das Tor-Repository zu eurer sources.list-Datei hinzu:

echo "deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] https://deb.torproject.org/torproject.org bullseye main" | sudo tee /etc/apt/sources.list.d/tor.list

Ersetzt bullseye durch den Codenamen eurer Distribution. Nehmt jammy fur Ubuntu 22.04, oder bookworm für Debiab 12.x. Für Ubuntu 24.04 und Linux Mint Cinnamon 22 gibt es aktuell kein Tor-Repos. Hier kann man aktuell noch die jammy Repos verwenden, welche auf Ubuntu 24.04 und Mint 22 funktionieren.

Fügt den entsprechenden GPG Schlüssel hinzu:

wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/tor-archive-keyring.gpg >/dev/null

Installiert nun die neuste Version von Tor:

sudo apt update && sudo apt install tor deb.torproject.org-keyring

Schritt 3: Tor installieren

Wer nicht immer die neuste Version jedes Programmes haben muss, und keine Lust auf Befehlszeite hat, kann sich Tor auch über die Systempakete installieren. Aktualisiert die Paketquellen und installiert Tor:

sudo apt update && sudo apt install tor

Danach ist Tor bereits installiert, und auch aktiviert und hört auf lokale Verbindungen auf Port 9050.

Überprüfen, ob Tor auch wirklich rennt, könnt ihr mit:

sudo systemctl status tor

Die korrekte Ausgabe wäre:

Telegram mit Tor verbinden

Als nächstes müssen wir nun Telegram nun so konfigurieren, dass es sich mit dem Tor-Server verbindet, um mit den Telegram Servern zu kommunizieren, dafür könnt ihr gleich mal in die Einstellungen gehen:

Danach geht ihr auf Advanced/Erweitert und danach auf Connection Type/Verbindungsart:

Hier wählt ihr jetzt eigenen Proxy hinzufügen und gebt die Daten wie folgt ein:

Verbindungstyp/Protokoll: SOCKS5 (Das Proxy-Protokoll fürs Netzwerk)
Serveradresse: 127.0.0.1 (das ist die lokale Adresse des Rechners)
Port: 9050 (Der Tor Port)

Benutzer und Passwort müsst ihr nicht angeben. Bestätigt mit Speichern. Nun verbindet sich Telegram zur erst mit dem lokalen Tor Server, welcher sich wiederum mit dem Onion Netzwerk verbindet. Ihr seid nun über das Tornetzwerk mit den Telegram Servern verbunden.

Hinweis: Anrufe werden per Standard nicht über das Tornetzwerk getunnelt, dafür müsst ihr die Option Proxy für Anrufe verwenden. Hier sei gesagt, dass dies nicht immer unterbrechungsfrei funktioniert, das das Tor Netzwerk eher langsam ist.

Es ist völlig normal dass die Chats teilweise etwas länger laden, vor allem merkt ihr es aber bei Bildern und Videos. Hier benötigt es einiges mehr Zeit, bis diese geladen werden.

Fazit

Die Nutzung von Telegram über das Tor-Netzwerk bietet eine zusätzliche Schicht an Sicherheit und Anonymität. Während Telegram bereits Ende-zu-Ende-Verschlüsselung nur in den Secret Chats verwendet, schützt der Einsatz von Tor vor der Offenlegung der eigenen IP-Adresse und bietet somit Schutz vor Tracking und Zensur. Dies ist besonders nützlich in Ländern mit strengen Internetkontrollen oder für Nutzer, die ihre Online-Privatsphäre erhöhen möchten. Allerdings sollte man bedenken, dass die Nutzung von Tor die Verbindungsgeschwindigkeit beeinträchtigen kann. Insgesamt ist die Kombination von Telegram und Tor ein effektiver Schritt für alle, die mehr Kontrolle über ihre digitale Privatsphäre wünschen.

Möchtet ihr dem Tor-Entwicklern etwas spenden? Dann schaut mal hier vorbei. Keine Ahnung von Ports, Protokollen und Verbindungstypen? Hier gibt es etwas Lesematerial.

The post Telegram über Tor auf Linux nutzen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Das Tutorial eignet sich sowie für den Raspiblitz, also auch für Umbrel, Start9, und MyNode Fullnode Betriebssysteme.

Vorausetzungen

Bevor ihr beginnt, stelle sicher, dass ihr folgende Dinge vorbereitet habt:

Computer mit Platz für 2 SSDs

• Ihr benötigt einen freien Computer, bzw. eine Arbeitsgerät, an dem ihr die 2 SSDs anklemmen könnt. Das kann auch ein Laptop sein, mit dem ihr die 2 SSDs via USB to SSD Adapter anschliesst.

GParted Live USB:

• Ladet das GParted Live-ISO von der offiziellen GParted Webseite herunter.
• Erstellt einen bootfähigen USB-Stick mit Rufus oder Balena Etcher.

SSD einbauen:

• Schließt beide SSDs an euren Rechner an.

Optional: Backup:

• Erstellt ein Backup der ersten SSD falls ihr auf Nummer sicher gehen wollt.

Vorbereitung

System vom GParted Live USB-Stick booten:

• Starte den Rechner neu und boote von deinem GParted Live USB-Stick. Achte darauf, im BIOS/UEFI den USB-Stick als erstes Bootmedium einzustellen.

GParted starten:

Im GParted Live-Boot-Menü wählt die Standardoptionen aus, bis ihr zur grafischen Oberfläche gelangt. Stellt sicher, dass ihr das richtige Tastaturlayout verwendet:

Wählt im nächsten Fenster eure Sprache aus, Deutsch ist in den meissten Fällen die Nummer 10. Nehmt danach den Modus 0:

Klonen der Partitionen

Quelllaufwerk auswählen

• Wählt die 1TB SSD aus dem Dropdown-Menü oben rechts in GParted aus. Ihr solltet die Partition(en) eurer 1TB SSD sehen.

Partition(en) kopieren

• Wählt die Partition, die ihr klonen möchtet (normalerweise die Hauptpartition mit euren Blockchaindaten und Diensten), und klickt mit der rechten Maustaste darauf. Wählt copy.

Ziellaufwerk auswählen

• Geht jetzt zur 2TB SSD im Dropdown-Menü. Klickt mit der rechten Maustaste auf den nicht zugewiesenen Speicherplatz auf der 2TB SSD und wählt paste.

Sollte auf der Ziel SSD bereits eine Partition bestehen, wählt diese einfach vorher aus, und löscht diese.

Anpassung der Partitiongrösse

Als nächst bekommt ihr ein Feld zu sehen, auf dem ihr die Partition gleich auf die Grösse der neuen SSD anpassen könnt:

Pakt den markierten Pfeil, und schiebt die neue Partition auf die volle Grösse der SSD. Klickt danach auf Paste.

Startet den Kopiervorgang mit dem grünen Haken:

Überprüfung und Testing

Hängt die neue SSD einfach an euren Raspiblitz an, er sollte automatisch alles erkennen, und dort weitermachen, wo er aufgehört hat. Anpassungen eurerseits sind nicht nötig.

Fazit

Mit GParted könnt ihr den Klonvorgang von einer 1TB auf eine 2TB SSD direkt und ohne zusätzliche Tools durchführen. Dies spart Zeit und erlaubt euch, alle notwendigen Schritte – vom Klonen bis zur Partitionserweiterung – in einer einzigen, vertrauten Umgebung durchzuführen. Indem ihr die Partition nach dem Klonen vergrößerst, stellt ihr sicher, dass ihr die volle Kapazität der neuen SSD nutzen könnt, sodass eure Blockchaindaten und Dienste weiterhin optimal funktionieren.

The post Fullnode 1TB SSD auf 2TB SSD klonen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Dank des eingebauten WiFi-Mikrocontrollers (ESP32-S3-WROOM-1) lässt sich die Bitaxe einfach in eures Netzwerk integrieren und mit eurem bevorzugten Mining-Pool verbinden. Wir schauen uns in diesem Artikel die Einrichtung und Anwendung der Bitaxe an. Das BitaxeOS ist OpenSource, und der Sourcecode kann auf Github betrachtet werden.

Die Bitaxen sind echte Vorreiter, da sie vollständig montiert und einsatzbereit geliefert werden. So wird der Einstieg in das Bitcoin-Mining zu einem Kinderspiel. Dank der intuitiven Benutzeroberfläche von AxeOS könnt ihr sofort mit dem Mining beginnen, ohne euch mit komplexen Konfigurationen auseinandersetzen zu müssen.

Welche Bitaxe passt zu mir? Die Modelle im Überblick (2026)

Die Bitaxe gibt es in mehreren Varianten, die sich vor allem im verbauten ASIC-Chip und damit in Hashrate und Effizienz unterscheiden. Aktuell (Stand 2026) ist die Gamma mit dem modernen BM1370-Chip das Flaggschiff und die effizienteste Einzelchip-Variante. Hier die gängigen Modelle im Vergleich:

Für die meisten Einsteiger ist die Bitaxe Gamma die beste Wahl: höchste Hashrate pro Chip bei der besten Effizienz. Wer mehrere Geräte leise und sparsam betreiben möchte („Swarming“, dazu unten mehr), fährt mit der Supra gut. Die folgende Einrichtung ist bei allen Modellen praktisch identisch, da sie alle dieselbe AxeOS-Firmware nutzen.

Vorbereitungen und Voraussetzungen

Ihr benötigt eigentlich nur einen Platz mit möglichst gutem 2.4Ghz WLAN Empfang. 5Ghz unterstützt das Gerät leider nicht. Die Reichweite ist bei 2.4Ghz meisst auch höher, und die Verbindung ist zuverlässiger und stabiler, wenn auch nicht so schnell, und von den Latenzen halt auch etwas höher.

Des weiteren benötigt ihr zudem ein Smartphone um die erste Verbindung zur BitAxe herzustellen.

Einrichtung und Anwendung der Bitaxe

Gerät anschließen

Schließt das Netzteil an die Bitaxe an und verbindet es mit einer Stromquelle. Es gibt keinen An- und Ausschalter. Das Gerät startet automatisch, sobald es mit Strom versorgt wird.

Verbindung zum Access Point herstellen

Der erste Start erfolgt über das WLAN Access Point des Geräts.

Sucht in eurem WLAN nach dem Access Point der Bitaxe. Der Name des Netzwerks (SSID) ist auf dem Gerät Display zu sehen.

Verbindet euch mit diesem WLAN. Es ist kein Passwort erforderlich, da es sich um einen offenen Access Point handelt.

Konfiguration über Captive Portal

Nachdem ihr euch mit dem Access Point verbunden habt, öffnet sich automatisch ein Captive Portal (ähnlich wie in Hotels oder öffentlichen Netzwerken).

Geht in den Reiter Network des Geräts. Gebt hier die SSID eures Heim- oder Unternehmensnetzwerks sowie das Passwort ein, um die Bitaxe in euer WLAN zu integrieren. Speichert die Einstellungen und startet das Gerät über das Interface ganz unten neu.

Hinweis: Ab Version 2.6.1 ist es neu das WLAN über die Lupe zu suchen, das Gerät scannt dann automatisch alle WLANs, und ihr könnt das richtige dann einfach mit einem klick auswählen, anstatt die SSID manuell einzugeben.

Zugriff auf die Benutzeroberfläche

Nach dem Neustart verbindet sich die Bitaxe mit eurem WLAN. Um auf das Dashboard zuzugreifen, ermittelt die IP-Adresse des Geräts (entweder über den Router oder einen IP-Scanner)

Öffnet euren Browser und gebt die IP-Adresse ein. Für das Webinterface ist kein Passwort erforderlich.

Pool- und Wallet Konfiguration

Im Dashboard in den Poolsettings findet ihr die "Pool-Einstellungen".

Pool ändern: Ihr könnt unseren gebührenfreien Schweizer Pool `blitzpool.yourdevice.ch` auf Port 3333 verwenden. Tragt diese Informationen in die entsprechenden Felder ein. Ihr könnt natürlich jeden anderen Pool eurer Wahl nehmen.

Wallet-Adresse: Löscht die Standard-Bitcoin-Adresse und fügt eure eigene Bitcoin-Adresse ein, um sicherzustellen, dass die Mining Belohnungen direkt an euch ausgezahlt werden. Nutzt eine Bitcoin Adresse von einer Hard- oder Softwarewallet eurer Wahl. Wählt ein Passwort damit ihr eure Statistiken auch auf https://blitzpool.yourdevice.ch einsehen könnt.

Hinter eure BTC Adresse könnt ihr einen Namen anhängen. Somit lassen sich bestimmte Worker Gruppen erstellen. Eine bestimmte Gruppe aus Minern kann damit erstellt werden. Das geht indem ihr hintere eure BTC Adresse einen Namen anhängt, separiert mit einem Punkt. Somit lassen sich bestimmte Worker Gruppen erstellen. Eine Kombination aus Minern könnte zum Beispiel so aussehen:

bc1qnu7xxxxxxxxxxxxxxxxxxxxxxptez73ch4.bitaxe heissen, eine weitere zum Beispiel
bc1qnu7xxxxxxxxxxxxxxxxxxxxxxptez73ch4.nerdminer

So lassen sich die Geräte voneinander trennen. Der Reward geht natürlich immer noch an die selbe BTC-Adresse.
In den Pool Statistiken tauchen die Geräte dann gruppiert und den jeweiligen Workernamen auf.

Damit die Einstellungen wirksam werden, müsst ihr unten auf Save klicken, und dann links in der Einstellungsleiste Restart auswählen.

Fallback Pool definieren: Seit dem Update auf die Version 2.3.0 könnt, oder ist ein Fallback Pool definiert. Falls der Primary Pool ausfällt, mint die Bitaxe im automatisch im Fallback Pool weiter.

Stratum V1 oder V2

Neu könnt ihr in den Pool-Einstellungen zwischen Stratum V1 (SV1) und dem moderneren Stratum V2 (SV2) wählen. SV2 verschlüsselt die Verbindung zwischen Miner und Pool (Schutz vor Man-in-the-Middle-Angriffen), kommt mit deutlich weniger Datenverkehr aus und erlaubt es Minern perspektivisch, ihre Blockvorlage selbst zu bestimmen – ein wichtiger Schritt für mehr Dezentralisierung im Bitcoin-Netzwerk. Die Hintergründe haben wir im Beitrag Stratum V2 – Warum das Bitcoin-Mining ein neues Protokoll braucht ausführlich erklärt.

Für SV2 benötigt ihr neben Host und Port zusätzlich den Authority Key (den Public Key des Pools). Zwei empfehlenswerte SV2-Pools:

• Blitzpool (unser Schweizer Solo-Pool, 0 %) – Host blitzpool.yourdevice.ch, Authority Key:
  9bCoFxTszKCuffyywH5uS5o6WcU4vsjTH2axxc7wE86y2HhvULU
  Die vollständigen Verbindungsdaten findet ihr auf blitzpool.yourdevice.ch/stratum-v2.
• Braiins Pool (gepoolt, die Entwickler von Stratum V2) – Host stratum-v2.braiins.com, Port 3336, Authority Key:
  u95GEReVMjK6k5YqiSFNqqTnKU4ypU2Wm8awa6tmbmDmk1bWt
  Aktuelle Werte stets in der offiziellen Braiins-Anleitung prüfen.

Übernehmt eure Auswahl wie gewohnt mit SAVE und einem anschliessenden RESTART. Im Zweifel funktioniert SV1 nach wie vor problemlos – SV2 ist die zukunftssichere, aber optionale Wahl.

Welchen Mining-Pool für die Bitaxe wählen?

Mit einer Bitaxe minet man in der Regel solo – ihr nehmt also an einer Art Lotterie teil: Die Chance, einen ganzen Block zu finden, ist klein, dafür erhaltet ihr im Erfolgsfall die komplette Block-Belohnung. Dass das kein reines Märchen ist, zeigt der erste mit einer Bitaxe Supra solo gefundene Block #887.212 im März 2025. Für das Solo-Mining haben sich diese Pools etabliert:

• Blitzpool – unser eigener Schweizer Public-Pool (auf Basis der quelloffenen Public-Pool-Software). 0 % Gebühren, übersichtliche Statistiken und dank Serverstandort Schweiz niedrige Latenz für CH/EU. Stratum: stratum+tcp://blitzpool.yourdevice.ch:3333
• eusolo.ckpool.org – die EU-Variante von Con Kolivas’ ckpool (eigener Server in der EU seit Ende 2024, dadurch deutlich geringere Latenz als das originäre solo.ckpool.org). 2 % Gebühr im Erfolgsfall.
• Public Pool – der originale, quelloffene Public-Pool. 0 % Gebühren und sogar selbst hostbar – genau die Software, auf der auch unser Blitzpool läuft.

Bevor ihr euch realistische Erwartungen setzt, lohnt sich ein Blick in unsere Beiträge Solo Mining – die grössten Fehlannahmen und Die kleine Bitcoin Solo Mining Bibel. Wer lieber regelmässige Kleinauszählungen statt der Lotterie möchte, findet im Artikel Bitcoin Mining Pool die Alternative.

Mining starten

Der Miner startet automatisch, sobald die Pooleinstellungen korrekt eingegeben und gespeichert wurden sind. Seht ihr keine Hashrate, stimmt was mit euren Pool-Einstellungen nicht.

Unten findet ihr noch Informationen zum aktuellen Stromverbrauch, der ASIC Spannung, der Lüfterdrehzahl und der aktuellen Temperatur des Chips

Leistungsoptimierung

Passt die Mining-Einstellungen wie Hashrate, Spannung und Lüftergeschwindigkeit an. Es ist ratsam, zunächst mit den Standardeinstellungen zu beginnen. Es sei gesagt dass man durch Overclocking das Gerät beschädigen kann, und dass man dadurch natürlich jedliche Garantien und Gewährleistungen verliert. Die Temperaturen sollten im Auge behalten werden, es empfiehlt sich, andere Kühlkörper und Lüfter als die Standardlüfter zu verwenden. Der Noktua Lüfter eignet sich auch eher weniger für das Übertakten, da dieser von Haus aus leiser arbeitet, und nicht besser.

Speichert die Einstellungen und startet die Bitaxe anschliessend neu, um eure Einstellungen zu übernehmen.

Advanced Overclocking

Fügt ihr im Browser am Ende der Adresse ?oc= ein, öffnet sich der erweiterte Overclocking Modus. Hier können die Werte manuell und frei gewählt werden. Es sind nahezu keine grenzen gesetzt. Bitte achtet besonders drauf was hier ihr eingebt. Ausversehen 1.5v Asic Spannung eingegeben führen dann ziemlich schnell zum Tot des Asic Chips.

Beispiel:

👉 192.168.1.21/#/settings
👉 192.168.1.21/#/settings?oc=

Monitoring und Wartung

Beobachte die Temperatur und die Hashrate im Dashboard. Der Asic Miner taktet automatisch herunter, sollte die Temperaturen über 65° steigen. Alles bis zu 65° ist vollkommen in Ordnung.

Reinigt ausserdem das Gerät auch regelmäßig, um Überhitzung durch Staubansammlungen zu verhindern.

Sicherheit und Updates

Haltet die Firmware des Geräts auf dem neuesten Stand, um optimale Leistung und Sicherheit zu gewährleisten.

Klickt dafür auf esp-miner.bin und ladet die Firmware herunter, und für das Web-UI auf www.bin. Danach wählt ihr unter Update Firmware Browse Button und wählt die esp-miner.bin und bei Update Webseite die www.bin. Das Gerät läd die Firmware automatisch, und muss danach neu gestartet werden.

Swarming

Ihr könnt im Tab Swarm eure Geräte verbinden, um sie jeweils von einer Bitaxe aus alle zu konfigurieren. Fügt dafür einfach unter AxeOS Device IP die IP Adresse der anderen Miner hinzu:

Bitaxe herunterfahren

Um die Bitaxe herunterzufahren, müsst ihr nichts anderes tun, als das Stromkabel zu trennen. Das tut der Bitaxe keinen Schaden, und wird auch das Betriebssystem nicht beschädigen.

Bitaxe zurücksetzen und wieder in den Acess Point Modus bringen

Geht einfach auf das Web-UI der jeweiligen Bitaxe, und löscht eure WLAN Daten wie die SSID und das WLAN Passwort. Startet das Gerät anschliessend neu. Das Gerät wird dann wieder in den AP-Modus gehen. Bei einem Verkauf eurer Bitaxe, löscht ihr am besten gleich noch sämtliche Einstellungen wie den Pool, eure BTC-Adresse, und das Passwort.

Firmware neu Flashen

Falls irgendwas mal total schief gegangen ist, und die Bitaxe nicht mehr reagiert, hilft es, die Firmware neu zu flashen. Auch kann es vorkommen, dass der Overheating Modus durch ein Missgeschickt aktiviert wird, wenn sich das Gerät noch nicht mit dem WLAN verbunden hat. In diesem Fall agiert die Bitaxe nicht mehr als Access Point und der Overheating Modus kann nicht deaktiviert werden.

Besucht den Link für dem Online Firmwareflasher:

https://bitaxeorg.github.io/bitaxe-web-flasher

Schliesst eure Bitaxe an den Strom, und verbindet die Bitaxe mit einem USB-C Kabel mit eurem Rechner.

Klickt danach auf Connect, und wählt die ttyUSB Verbindung. Wählt das richtige Gerät, und das richtige Board aus, und beginnt das flashen der Firmware mit Start Flashing. Die Firmware wird nun auf eure Bitaxe geflasht. Die Bitaxe führt, danach einen Funktionscheck durch. Danach müsst ihr die Bitaxe noch neu starten, und sie befindet sich wieder im AP Modus.

Fazit

Mit der Bitaxe seid ihr bestens gerüstet, um in die Welt des Bitcoin-Minings einzutauchen. Die Einrichtung ist dank der benutzerfreundlichen Bedienoberfläche und einfachen Netzwerkanbindung schnell erledigt. Ob ihr ein erfahrener Miner oder Neueinsteiger seid – die Flexibilität und Leistungsfähigkeit dieses Geräts ermöglichen es euch, das Beste aus eurem Mining-Erlebnis herauszuholen. Sobald die Konfiguration abgeschlossen ist und der Miner korrekt läuft, könnt ihr entspannt zurücklehnen, während die Bitaxe effizient und zuverlässig ihre Arbeit erledigt. Viel Erfolg!

Falls ihr auf der Suche nach 'ner Bitaxe seid, schaut mal bei uns im Shop vorbei!

Sucht ihr nach mehr Infos und Theorie zum Mining, dann haben wir die kleine Bitcoin Mining Bibel für euch:

Habt ihr Lust unserem Mining Pool beizutreten? Unser Ziel ist es, in der Schweiz einen Block zu finden. Mit den Jungs aus der Schweiz und Plebs aus verschiedenen Ländern haben wir bereits gut Hashrate zusammen!

Nehmt euren Miner in die Hand, und konfiguriert diesen auf unseren Pool:

Stratum Host: blitzpool.yourdevice.ch
Port: 3333
Alternativer Port: 4444

Wir betreiben einen stark modifizierten Public-Pool Fork der welcher extrem erweitert worden ist, und sich auch fürs Mining mit Freunden eignet. Somit habt ihr, wenn ihr zusammen auf einer Adresse schürft, eure Worker komplett im Überblick.

Pool UI: https://blitzpool.yourdevice.ch

Häufige Fragen zur Bitaxe

Lohnt sich Solo-Mining mit einer Bitaxe?

Finanziell betrachtet ist es eine Lotterie: Die Wahrscheinlichkeit, mit einem einzelnen Gerät einen Block zu finden, ist sehr gering. Viele betreiben eine Bitaxe daher aus Überzeugung – um das Netzwerk zu dezentralisieren, zu lernen und die Chance auf den „Lottogewinn“ mitzunehmen – statt als zuverlässige Einnahmequelle.

Welche Bitaxe eignet sich für Einsteiger?

Die Bitaxe Gamma mit BM1370-Chip ist aktuell die Empfehlung: beste Effizienz (~15 J/TH) und höchste Hashrate aus einem einzelnen Chip. Sie kommt fertig montiert und läuft direkt mit der AxeOS-Firmware.

Wie viel Strom verbraucht eine Bitaxe?

Je nach Modell und Taktung etwa 12 bis 21 Watt. Eine Supra liegt um die 12 W, eine Gamma bei rund 15–21 W. Im „PowerSave“-Betrieb lässt sich der Verbrauch zugunsten der Effizienz weiter senken.

Ist die Bitaxe wirklich Open Source?

Ja. Sowohl das Hardware-Design als auch die Firmware AxeOS (ESP-Miner) sind quelloffen und auf GitHub einsehbar. Das ist einer der grössten Vorteile gegenüber herkömmlichen Closed-Source-Minern.

Zuletzt aktualisiert im Juni 2026 – Modellübersicht (inkl. Gamma BM1370), Pool-Empfehlungen und FAQ ergänzt.

The post Bitaxe Miner Einrichtung und Anwendung appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Vorbereitung

Bevor ihr beginnt, sind einige Vorbereitungen notwendig:

• Backup: Macht wenn möglich ein vollständiges Backup eurer Daten auf dem bestehenden Smartphone, insbesondere wenn ihr sensible Informationen übertragt. Nutzt dafür lokale Lösungen wie USB Sticks oder eine SD-Karte.
• Passwörter & Logins: Stelle sicher, dass ihr alle notwendigen Passwörter und Anmeldedaten parat habt, da ihr diese möglicherweise auf dem neuen Gerät neu eingeben musst.
• Nextcloud einrichten: Wenn ihr Nextcloud verwenden möchtet, stellt sicher, dass ihr Zugriff auf euren Nextcloud-Server habt und die entsprechende App auf beiden Geräten installiert ist.

Datenübertragung von Android zu einem Custom ROM

Methode 1: Übertragung via USB-Kabel

1. Geräte verbinden: Verbindet euer altes Android-Gerät über ein USB-Kabel mit eurem Computer. Geht in die Benachrichtigungszentrale, und geht auf Benachrichtigung Gerät wird über USB geladen oder ähnlich. Möglicherweise müsst ihr die Benachrichtigung 2x antippen. Es öffnet sich ein neues Fenster, wählt hier Datenübertragung aus.
2. Datenübertragung starten:
   • Öffnet den Dateiexplorer auf eurem Computer und navigiert zu eurem Android-Gerät.
   • Kopiert die gewünschten Dateien (z.B. Fotos, Videos, Dokumente) auf euren Computer.
3. Übertragung auf das neue Gerät:
   • Verbindet nun euer neues Custom ROM-Gerät mit dem Computer. Aktiviert wieder die Datenübertragung.
   • Übertragt die zuvor gesicherten Daten vom Computer auf das neue Gerät, indem du sie in die entsprechenden Ordner kopierst (z.B. in den „DCIM“-Ordner für Fotos). Stellt sicher, das die Daten zum in den selben Ordnern landen, in denen sie vorher lagen. Erstellt falls nötig die entsprechenden Ordnernamen neu.

Methode 2: Übertragung über Nextcloud

1. Nextcloud-Client auf dem alten Gerät installieren:
   • Öffne die Nextcloud-App und meldt euch an.
   • Wählt die Dateien aus, die ihr sichern möchtest, und ladet sie in eure Nextcloud hoch.
2. Nextcloud-Client auf dem neuen Gerät installieren:
   • Öffnt die Nextcloud-App auf eurem neuen Custom ROM-Gerät und meldet euch mit eurem Account an.
   • Lade die gesicherten Dateien aus der Cloud auf euer neues Gerät herunter.

Methode 3: Direktes Gerät-zu-Gerät-Kabel

1. USB-OTG-Kabel verwenden:
   • Wenn beide Android-Geräte USB-OTG (On-the-Go) unterstützen, könnt ihr sie direkt miteinander verbinden.
   • Verwendet eine Dateiübertragungs-App (z.B. „Files by Google“), um Daten direkt zwischen den Geräten zu kopieren.

Datenübertragung von iPhone zu einem Custom ROM

Methode 1: Übertragung via USB-Kabel

1. Daten vom iPhone auf den Computer übertragen:
   • Verbindt euer iPhone über ein USB-Kabel mit eurem Computer.
   • Verwende iTunes (auf Windows) oder den Finder (auf macOS), um auf die Dateien zuzugreifen. Für Linux gibt es leider kein entsprechendes Programm. Ihr benötigt also einen Windows oder MacOS Rechner
   • Kopiert die gewünschten Dateien auf euren Computer.
2. Übertragung auf das neue Android-Gerät:
   • Verbindet das neue Gerät mit dem Computer. Aktiviert wieder den Datenübertragungsmodus.
   • Kopiert die Dateien vom Computer auf das neue Gerät.

Methode 2: Übertragung über Nextcloud falls kein Windows oder MacOS Rechner verfügbar

1. Nextcloud-Client auf dem iPhone installieren:
   • Öffnet die Nextcloud-App und meldet euch an.
   • Wählt die Dateien aus, die ihr sichern möchtet, und ladet sie in eure Nextcloud hoch.
2. Nextcloud-Client auf dem neuen Android-Gerät installieren:
   • Öffnet die Nextcloud-App auf eurem neuen Custom ROM-Gerät und meldet euch mit eurem Account an.
   • Ladet die gesicherten Dateien aus der Cloud auf euer neues Gerät herunter.

Spezifische Datenübertragungen

Kalender

• Android zu Android:
  • Exportieret eure Kontakte als .vcf-Datei und deinen Kalender als .ics-Datei. Nutzt dafür die App Fossify Contacts und Fossify Calender um die Kontakte zu exportieren, und wieder zu importieren.
  • Übertrage diese Dateien via USB oder Nextcloud auf das neue Gerät und importiere sie dort.
• iPhone zu Android:
  • verwendet dafür folgendes Tutorial:

Kontakte und SMS

Wie ihr eure Kontakte und SMS übertragen könnt, erfahrt ihr hier in diesem Artikel:

Messaging-Apps

• WhatsApp: Verwende die lokale Backup-Funktion von WhatsApp, um ein Backup auf eurem alten Gerät zu erstellen. Das Backup befindet sich im Ordner /android/media/com.whatsapp Übertragt den kompletten Ordner com.whatsapp via USB oder Nextcloud auf das neue Gerät in den selben Ordner und stelle es bei der Einrichtung von WhatsApp wieder her. Ihr dürft Whatsapp vorher nicht starten!
• Signal: Signal bietet eine integrierte Backup- und Wiederherstellungsfunktion, die ihr ebenfalls lokal sichern und auf dem neuen Gerät wiederherstellen könnt. Die Funktion befindet sich in den Einstellungen unter Chats und dann unten unter Chat-Sicherungen. Schreibt euch die Passphrase auf, und ladet die Datei auf euer neues Phone. Installiert euch Signal oder Molly, und wählt Aus Sicherung wiederherstellen, beim starten der App.
• Telegram: Da Telegram cloudbasiert ist, müsst ihr euch nur mit eurem neuen Account auf dem neuen Phone anmelden.
• Threema: bietet in den Einstellungen ebenfalls eine Sicherungsfunktion. Ihr benötigt aber unbedingt euren Threema Key, den ihr beim Kauf erhalten habt, und müsst euch Threema Libre aus dem F-Droid Store installieren. Dort könnt ihr das Backup File dann wieder herstellen.

Weitere Apps wie Notiz Apps und etc.

Viele Apps bieten eine Sicherungsfunktion, nutzt wenn möglich die Sicherungsfunktionen der Apps die ihr verwendet, und stellt diese auf dem neuen Gerät wieder her.

Abschließende Schritte

• Datenüberprüfung: Stelle sicher, dass alle Daten korrekt auf das neue Gerät übertragen wurden und einwandfrei funktionieren.
• Apps installieren: Installiere alle notwendigen Apps manuell über F-Droid oder andere sichere Quellen.
• Sicherheit: Überprüfe, ob alle sicherheitsrelevanten Einstellungen auf dem neuen Gerät aktiviert sind, insbesondere Verschlüsselung und Authentifizierung.

VCool, dass du dieses Tutorial zur Datenübertragung auf Custom ROMs wie GrapheneOS oder CalyxOS gelesen habt, heisst also ihr seid bereits in gewissen Vorbereitungsphasen! Der Wechsel zu einem Custom ROM kann ein großer Schritt sein, besonders wenn es um die Sicherung und Übertragung eurer wertvollen Daten geht. Mit den richtigen Tools und der richtigen Vorgehensweise könnt ihr jedoch sicherstellen, dass der Übergang reibungslos verläuft und ihr die Vorteile eines sicheren und datenschutzorientierten Betriebssystems voll ausschöpfen könnt.

Vergesst nicht, regelmäßig Backups eurer Daten zu erstellen und euch über Updates und neue Funktionen eures Custom ROMs auf dem Laufenden zu halten. Wenn ihr Fragen oder Herausforderungen während der Übertragung hast, zögere nicht, in der Community nach Unterstützung zu suchen – es gibt viele erfahrene Nutzer, die euch gerne weiterhelfen.

The post Daten auf CustomROM mit CalyxOS / GrapheneOS übertragen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Voraussetzungen

1. Server: Ihr benötigt einen Server mit einem modernen Linux-Betriebssystem (z.B. Ubuntu 22.04 oder Debian 12.6). (Achtung, es eigenet sich kein LXC Container auf Proxmox Systemem, es muss eine virtuelle Maschine sein!) Am besten man mietet sich für seinen eigenen Collabora Online Server eine günstige VPS bei einem Provider eurer Wahl. Je nach Nextcloud Instanzen die bedient werden sollen, reichen 2-4 CPU Kerne und 4-6GB RAM. Es ist zudem sinnvoll, wenn der Collabora Server auf einem eigenen Server läuft, und nicht auf einer der Nextcloud Server.
2. Docker und Docker Compose: Stellt sicher, dass Docker und Docker Compose auf eurem Server installiert sind.
3. Port Forwarding und Firewall im Homelab: Falls ihr eure Nextcloud im eigenen Netzwerk betreibt, muss ein ReverseProxy vorgeschalten werden, das kann zum Beispiel der NginxProxyManager sein, oder zum Beispiel auch HAProxy, welcher auf einer pfSense Firewall läuft, damit die Nextcloud Instanz, und der Collabora Office Server hinter eurer IP beide erreichbar sind. Die Portweiterleitung für die Collabora Instanz ist Source Port 443 und Destination Port 9980 falls die SSL Terminierung über einen vorgeschaltenen Proxy wie den Nginx Proxy Manager geschieht.
4. Port Forwarding und Firewall auf einer VPS: es müssen nur Port 80 und 443 freigegeben werden. Ein Port Fowarding auf einer VPS ist nicht nötig da dieser über eine öffentliche IP verfügt.
5. Domain: Ihr benötigt eine gültige Domain für den Office Server. Bei einer Verwendung zuhause im Homelab mit dynamischer IP empfiehlt sich eine DynDNS Domain.

Docker Installation (Ubuntu & Debian)

sudo apt-get update
sudo apt-get install apt-transport-https ca-certificates curl gnupg lsb-release

Den Docker Repository GPG Key hinzufügen:

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

Tauscht ubuntu gegen debian aus bei einem reinen Debian System

Fügt das Repository zu euren Quellen hinzu und updatet die Packete:

echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update

Auch hier ubuntu gegen debian austauschen falls ihr ein Debian System fahrt.

Jetzt können wir Docker installieren:

sudo apt-get install docker-ce docker-ce-cli containerd.io

Docker Befehle ohne Sudo verwenden (optional)

sudo usermod -aG docker $USER

Verzeichnisstruktur anlegen

Erstelle ein neues Verzeichnis für eure Collabora-Installation und wechselt gleich in das Verzeichnis:

mkdir -p ~/collabora && cd ~/collabora

Docker Compose Datei erstellen

Erstellt eine neue Datei namens docker-compose.yml im ~/collabora-Verzeichnis mit folgendem Inhalt:

version: '3.3'

services:
  collabora:
    image: collabora/code:latest
    container_name: collabora_app
    environment:
      - aliasgroup1=https://cloud1.yourdomain.com
      - aliasgroup2=https://cloud2.yourdomain.com
      - "extra_params=--o:ssl.enable=false --o:ssl.termination=true"
    cap_add:
      - MKNOD
    ports:
      - "9980:9980"
    restart: unless-stopped

Ersetzt cloud1.euredomaine.com und cloud2 mit der Domain eurer Nextcloudinstanzen, ansonsten können die Nextcloud Instanzen nicht mit dem Collabora Server kommunizieren.

Wichtig ist, dass der Reverse Proxy die SSL Terminierung vornimmt, und über ein geeignetes SSL Zertifkat verfügt, zum Beispiel von LetsEncrypt.

Wer sich ein selbstsigniertes Zertifkat vom Collabora Server erstellen lassen will, ändert die Zeile:

- "extra_params=--o:ssl.enable=false --o:ssl.termination=true"

zu

- "extra_params=--o:ssl.enable=true --o:ssl.termination=false"

ab

Ein selbstsigniertes Zertifkat kann dann verwendet werden, wenn der Collabora Server auf einer Virtuellen Maschine zum Beispiel auf eurem Proxmox Host läuft.

Erläuterungen zur docker-compose.yml:

• image: Hier geben wir die spezifische Version von Collabora an, die verwendet werden soll (collabora/code:latest) also jeweils das neuste Image.
• environment: Mit aliasgroup1 und aliasgroup2 werden die URLs euer Nextcloud-Instanzen angegeben. Diese müssen natürlich durch die tatsächlichen URLs euer Nextcloud-Instanzen ersetzt werden.
• ports: Port 9980 wird nach außen freigegeben, sodass Collabora über diesen Port erreichbar ist.
• restart: Mit unless-stopped wird der Container automatisch neu gestartet, wenn er unerwartet beendet wird.

Schritt 3: Docker Compose starten

Um den Collabora Server zu starten, führt folgenden Befehl im ~/collabora Verzeichnis aus:

docker-compose up -d

Dieser Befehl startet den Collabora Server im Hintergrund (-d für detached mode).

Konfiguration in Nextcloud

Jetzt müsst ihr eure Nextcloud-Instanzen konfigurieren, damit sie mit dem neuen Collabora-Server zusammenarbeiten.

1. In Nextcloud einloggen: Loggt euch in jede Nextcloud-Instanz ein, die ihr mit Collabora verbinden möchtet.
2. Nextcloud Office installieren: installiert euch die Office Suite von Nextcloud aus dem App Store.
3. Einstellungen: Geht zu den Collabora-Einstellungen in Nextcloud (Admin-Bereich) und gebt die URL eures Collabora-Servers ein (z.B. https://collabora.yourdomain.com).
4. Falls ihr ein selbstsigniertes Zertifikat verwendet, deaktiviert die den Zertifikatencheck.

Setzt weiter unten in den Erweiterten Einstellungen die IP Adresse des Collabora Servers unter Allow list for WOPI requests.

SSL-Zertifikate bei VPS Installationen

Falls ihr den Collabora Server auf einer VPS betreibt, empfiehlt es sich ein LetsEncrypt Zertifikat zu verwenden. Dies wird häufig mit einem Reverse Proxy wie Nginx oder Traefik gemacht, der das SSL-Zertifikat bereitstellt für die Verschlüsselung. Nginx läuft dabei auf dem Server, auf dem der Collabora Online Server läuft.

Hier ist ein einfaches Beispiel für einen Nginx-Proxy:

server {

 listen 443 ssl;

 server_name collaboraonline.example.com;

 ssl_certificate /etc/letsencrypt/live/collaboraonline.example.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/collaboraonline.example.com/privkey.pem;

 # Empfohlene SSL-Einstellungen für zusätzliche Sicherheit
 ssl_protocols TLSv1.2 TLSv1.3;
 ssl_ciphers HIGH:!aNULL:!MD5;
 ssl_prefer_server_ciphers on;

 # Pfad zu den SSL-Einstellungen von Certbot (optional, wenn von Certbot verwendet)
 include /etc/letsencrypt/options-ssl-nginx.conf;
 ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

 # Statische Dateien
 location ^~ /browser {
   proxy_pass https://127.0.0.1:9980;
   proxy_set_header Host $http_host;
 }

 # WOPI Discovery URL
 location ^~ /hosting/discovery {
   proxy_pass https://127.0.0.1:9980;
   proxy_set_header Host $http_host;
 }

 # Capabilities
 location ^~ /hosting/capabilities {
   proxy_pass https://127.0.0.1:9980;
   proxy_set_header Host $http_host;
 }

 # Haupt-WebSocket für Dokumentenbearbeitung
 location ~ ^/cool/(.*)/ws$ {
   proxy_pass https://127.0.0.1:9980;
   proxy_set_header Upgrade $http_upgrade;
   proxy_set_header Connection "Upgrade";
   proxy_set_header Host $http_host;
   proxy_read_timeout 36000s;
 }

 # Download, Präsentation und Bild-Upload
 location ~ ^/(c|l)ool {
   proxy_pass https://127.0.0.1:9980;
   proxy_set_header Host $http_host;
 }

 # Admin-Konsole WebSocket
 location ^~ /cool/adminws {
   proxy_pass https://127.0.0.1:9980;
   proxy_set_header Upgrade $http_upgrade;
   proxy_set_header Connection "Upgrade";
   proxy_set_header Host $http_host;
   proxy_read_timeout 36000s;
 }

}

Hier auch auch eine simple Nginx Config, für eine Zertifikatsbeantragung via certbot

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;

    location / {
        proxy_pass http://localhost:9980;  # Dies ist das Backend, also der Collabora Docker Container
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Die finale Nginx-SSL Konfiguration muss dann anhand des Beispiels oben natürlich erweitert werden.

Hier die Vorgaben von Collabora selber:

https://sdk.collaboraonline.com/docs/installation/Proxy_settings.html

Testen und Verwalten

Nachdem alles eingerichtet ist, könnt ihr in Nextcloud ein neues Dokument erstellen und es sollte automatisch über den Collabora-Server geöffnet werden. Achtet darauf, die Logs zu überwachen, um sicherzustellen, dass alles reibungslos läuft:

docker logs -f collabora_app

Collabora Server updaten

Um die Collabora Version zu updaten, musst der Tag latest hinter dem Image verwendet werden. Navigiert in den Ordner in der die docker-compose.yml liegt. Stoppt den Container mit

docker compose down

zieht euch das neuste Image mit:

docker compose pull

und fahrt die Kiste wieder hoch mit:

docker compose up -d

Zusammenfassung

Dieses Tutorial führt euch durch die Schritte, um einen Collabora Online Server mit Docker und Docker Compose aufzusetzen und für mehrere Nextcloud-Instanzen zu konfigurieren. Durch die Verwendung von Docker bleibt das Setup flexibel und einfach zu verwalten. Wenn ihr eine SSL-Verschlüsselung benötigt, könnt ihr dies leicht über einen Reverse Proxy wie Nginx implementieren.

Weitere Nextcloud Tutorials findet ihr in der Kategorie Nextcloud.

The post Eigenen Collabora Online Server installieren für Nextcloud appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Linux Mint: Update Manager

Der Update Manager in Linux Mint ist eines der benutzerfreundlichsten Tools zur Verwaltung von Systemupdates. Hier sind einige wichtige Punkte:

• Zugriff: Ihr könnt den Update Manager über das Menü oder das kleine Schild-Symbol im System-Tray öffnen.
• Funktion: Der Update Manager listet verfügbare Updates auf und stuft sie nach in Anwendungsupdates, Sicherheitsupdates oder Systemupdates ein.
• Update-Optionen: Ihr könnt einzelne Updates auswählen oder alle auf einmal installieren. Der Update Manager zeigt auch an, ob ein Neustart erforderlich ist.
• Kernel-Management: Linux Mint bietet eine einfache Möglichkeit, verschiedene Kernel-Versionen zu verwalten und alte Kernel-Versionen zu entfernen.
• Automatische Updates: In den Einstellungen könnt ihr automatische Updates aktivieren, wobei ihr festlegen könnt, welche Arten von Updates (z.B. nur Sicherheitsupdates) automatisch installiert werden sollen.

Empfehlung: aktiviert die automatische Wartung auf euren Linux Mint System um ältere Software und ältere Kernel nach einem Update Durchlauf zu löschen:

Updaten könnt ihr einfach indem ihr Refresh oder Aktualisieren auswählt, und danach Install Updates oder Updates installieren je nach Sprache:

Bestätigt das updaten einfach und lass den Updater alles machen. Manchmal werden Euch weitere Abhängigkeiten angezeigt, die aktualisiert werden müssen. Hier könnt Ihr ebenfalls einfach bestätigen.

Ubuntu: Update Manager (Software Updater)

Ubuntu hat ebenfalls einen grafischen Update-Manager, der als „Aktualisierungsverwaltung“ bekannt ist:

• Zugriff: Der Software Updater kann über das Menü oder das Zahnradsymbol in der Systemleiste aufgerufen werden, wenn Updates verfügbar sind. Ihr findet dort einen Button mit dem Namen Einstellungen.
• Funktion: Der Software Updater durchsucht das System nach verfügbaren Updates und zeigt sie in einer übersichtlichen Liste an. Er unterscheidet dabei nicht nach Wichtigkeit, sondern zeigt alle verfügbaren Updates gleichwertig an.
• Benachrichtigungen: Ubuntu benachrichtigt euch automatisch, wenn Updates verfügbar sind. Dies geschieht in regelmäßigen Abständen, die ihr in den Einstellungen anpassen könnt.
• LTS-Upgrade: Für Nutzer von Long-Term Support (LTS)-Versionen bietet der Update Manager die Möglichkeit, ein Upgrade auf die nächste LTS-Version durchzuführen, sobald diese verfügbar ist.
• Automatische Updates: In den Einstellungen unter „Software & Updates“ könnt ihr automatische Sicherheitsupdates aktivieren. Ubuntu unterstützt auch die Installation von „unattended-upgrades“, was besonders nützlich für Server ist.

Debian: Synaptic Package Manager & apt

Debian bietet standardmäßig keinen dedizierten grafischen Update-Manager, aber es gibt Tools wie Synaptic, die ihr verwenden könnt:

• Synaptic Package Manager: Synaptic ist ein grafisches Frontend für apt und bietet eine umfassende Möglichkeit, Pakete zu verwalten. Ihr könnt Synaptic verwenden, um Updates zu suchen und zu installieren, aber es zeigt euch keine expliziten Update-Benachrichtigungen an.
• Zugriff: Installiert Synaptic über das Terminal (sudo apt install synaptic) und öffnet es über das Menü.
• Funktion: Mit Synaptic könnt ihr nach Updates suchen, Pakete installieren, entfernen und verwalten. Es ist mächtiger und detaillierter als die Update-Manager von Mint und Ubuntu, erfordert aber auch ein besseres Verständnis der Paketverwaltung.
• Anderer Desktop: Wenn ihr eine Gnome oder KDE-Desktop-Umgebung nutzt, könnt ihr das „Gnome bzw. KDE Software“-Center verwenden, das ähnlich wie der Ubuntu Software Updater funktioniert und Updates grafisch anzeigt und installiert.
• Benachrichtigungen: Debian selbst gibt keine automatischen Benachrichtigungen über verfügbare Updates aus. Ihr müsst entweder regelmäßig manuell nach Updates suchen oder ein Tool wie unattended-upgrades einrichten.

Gemeinsame Merkmale

• Sicherheit: Alle drei Systeme haben Möglichkeiten, automatische Sicherheitsupdates einzurichten (Debian via unattend-upgrades). Diese Funktion ist besonders nützlich, um sicherzustellen, dass euer System immer gegen bekannte Sicherheitslücken geschützt ist.
• Zusätzliche Einstellungen: Bei allen drei Distributionen könnt ihr in den Einstellungen festlegen, welche Art von Updates ihr sehen möchtet (nur LTS, nur Sicherheitsupdates etc.) und wie oft ihr benachrichtigt werden möchtet.

Fazit

Während alle drei Systeme grafische Tools für Updates anbieten, sind Linux Mint und Ubuntu am benutzerfreundlichsten. Debian erfordert etwas mehr Handarbeit oder den Einsatz von zusätzlichen Tools wie Synaptic, um Updates grafisch zu verwalten. Letztendlich ist es jedoch Geschmackssache, ob ihr lieber auf die grafischen Update-Manager setzt oder die Kontrolle über das Terminal bevorzugt. Alle Methoden führen zum Ziel: ein stets aktuelles und sicheres System.

Updaten über die Kommandozeile

Für Debian Systeme schauen wir uns noch das updaten über die Kommandzeile an. Synaptic wird eigentlich nicht wirklich benötigt, und es geht sogar schneller das System über die Kommandozeile zu updaten.

Allgemeine Vorbereitungen

Bevor ihr beginnt, solltet ihr sicherstellen, dass ihr administrative Rechte hast. Ihr benötigt Zugriff auf den sudo-Befehl, um Systemupdates durchzuführen.

Backup

Es ist immer eine gute Idee, vor allem bei grösseren Updates ein Backup wichtiger Daten zu erstellen, und auch insbesondere wenn es sich um ein größeres Systemupdate oder eine neue Version handelt. Nutzt dafür Tools wie Timeshift und externe Festplatten.

Terminal öffnen

Das Update wird über das Terminal durchgeführt. Öffnet das Terminal, entweder über das Menü oder mit der Tastenkombination Strg + Alt + T.

System-Updates durchführen

Paketliste aktualisieren

Zuerst aktualisieren wir die Paketliste, damit das System weiß, welche Updates verfügbar sind:

sudo apt update

Dieser Befehl synchronisiert die Paketlisten aus den konfigurierten Quellen (Repositories).

System-Upgrades durchführen

Um die auf dem System installierten Pakete auf die neueste Version zu bringen, nutzt ihr den folgenden Befehl:

sudo apt upgrade

Dieser Befehl installiert alle verfügbaren Updates für bereits installierte Pakete, ohne Pakete zu entfernen oder neue Pakete zu installieren.

Volles Upgrade (empfohlen)

Es wird empfohlen, ein vollständiges Upgrade durchzuführen, um sicherzustellen, dass alle Pakete auf dem neuesten Stand sind und Abhängigkeiten korrekt gelöst werden. Dieser Befehl kann auch neue Abhängigkeiten installieren und veraltete Pakete entfernen:

sudo apt full-upgrade

Ein full-upgrade unterscheidet sich von upgrade, da es auch Pakete entfernen kann, wenn dies für ein Upgrade notwendig ist.

Autoremove und Autoclean (optional, aber empfohlen)

Um nicht mehr benötigte Pakete zu entfernen, die nach einem Update übrig bleiben (z.B. alte Kernel-Versionen oder Abhängigkeiten), verwendet den folgenden Befehl:

sudo apt autoremove -y && sudo apt autoclean -y

Spezielle Hinweise für Linux Mint, Debian und Ubunt

Linux Mint

Linux Mint hat ein zusätzliches Tool namens mintupdate, das eine benutzerfreundliche Oberfläche bietet um die Systemversionen zu updaten. Ihr könnt damit auch die oben beschriebenen Befehle über eine GUI ausführen. Trotzdem ist der Terminal-Ansatz der zuverlässigste Weg. Für ein Distributionsupgrade auf eine neue Version verwendet ihr:

sudo apt update && sudo apt dist-upgrade

Debian

Debian wird oft als sehr stabil angesehen und neigt dazu, konservativer mit Updates umzugehen. Wenn ihr Debian verwendet, könnt ihr sicher sein, dass die meisten Updates sehr gut getestet wurden. Es kann jedoch sein, dass einige Updates länger dauern, bis sie verfügbar sind.

Ubuntu

Ubuntu hat einen regelmäßigen Veröffentlichungszyklus (alle sechs Monate eine neue Version und alle zwei Jahre eine LTS-Version). Wenn ihr eine neue Ubuntu-Version installiert, stelle sicher, dass ihr das System nach der Installation sofort auf den neuesten Stand bringt. Ubuntu hat auch das Tool unattended-upgrades, das automatische Sicherheitsupdates ermöglicht.

Reboot nach Updates

Manche Updates, insbesondere Kernel-Updates, erfordern einen Neustart, um wirksam zu werden. Es wird empfohlen, das System nach einem Update neu zu starten, um sicherzustellen, dass alle Änderungen übernommen wurden:

sudo reboot

Troubleshooting

Falls beim Update Probleme auftreten, wie z.B. Paketkonflikte oder Abhängigkeitsprobleme, können die folgenden Schritte hilfreich sein:

• Paketkonflikte lösen: Verwendet sudo apt --fix-broken install, um beschädigte Abhängigkeiten zu reparieren.
• Logdateien prüfen: Schaut in die Protokolle unter /var/log/apt/, um detaillierte Informationen über den Fehler zu erhalten. Hier erhaltet Hilfe zu den Ausgaben in gängigen Linux Foren.
• Paketmanager-Sperre: Wenn der Paketmanager blockiert ist, prüft, ob eine andere Instanz von apt läuft, und beende sie ggf. mit sudo killall apt.

Weitere Tipps Automatische Updates aktivieren: Wenn ihr nicht regelmäßig manuell updaten möchtet, könnt ihr automatische Updates aktivieren, insbesondere für Sicherheitsupdates.

Paketquellen prüfen: Es kann sinnvoll sein, die Liste der Paketquellen regelmäßig zu überprüfen, um sicherzustellen, dass sie aktuell und korrekt konfiguriert sind.

Das Überprüfen der Paketquellen (auch bekannt als „Repositories“) ist eine wichtige Aufgabe, um sicherzustellen, dass dein System die neuesten und vertrauenswürdigen Updates erhält. Hier ist eine Schritt-für-Schritt-Anleitung, wie ihr die Paketquellen für Linux Mint, Ubuntu und Debian überprüfen könnt.

Paketquellen überprüfen auf Mint, Ubuntu und Debian

Paketquellen prüfen in Linux Mint

Über den Update-Manager

Linux Mint bietet eine einfache Möglichkeit, die Paketquellen über den Update-Manager zu überprüfen und zu bearbeiten:

1. Öffnet den Update-Manager: Klickt auf das Schild-Symbol in der Systemleiste oder sucht im Menü nach „Update-Manager“.
2. Quellen ändern: Klickt im Update-Manager auf „Bearbeiten“ und wählt „Paketquellen“ aus. Dies öffnet ein Fenster, in dem ihr die aktiven Paketquellen sehen und ändern könnt.
3. Überprüft die Liste: In den Tabs „Offizielle Repositories“, „PPA“ (Personal Package Archives) und „Zusätzliche Repositories“ könnt ihr sehen, welche Quellen verwendet werden.
4. Quellen ändern oder deaktivieren: Ihr könnt hier die Quellen ändern, hinzufügen oder deaktivieren. Stellt sicher, dass alle verwendeten Repositories vertrauenswürdig und für eure Linux Mint-Version geeignet sind.

Manuell über die Datei /etc/apt/sources.list

Ihr könnt auch direkt die Datei /etc/apt/sources.list und die zusätzlichen Dateien im Verzeichnis /etc/apt/sources.list.d/ überprüfen:

1. Öffnet das Terminal: Strg + Alt + T
2. Bearbeitet die Quellenliste: Verwende einen Texteditor wie nano, um die Datei zu öffnen:

   sudo nano /etc/apt/sources.list

3. Prüft und bearbeite die Datei: Überprüft, ob die Einträge aktuell und korrekt sind. Falls notwendig, könnt ihr hier auch Änderungen vornehmen. Falls Quellen fehlerhaft sind, meldet sich das System bei Updates.

Paketquellen prüfen in Ubuntu

Über die Software & Updates GUI

Ubuntu bietet eine grafische Oberfläche zur Verwaltung der Paketquellen:

1. Öffnet Software & Updates: Geht zu den Systemeinstellungen und wähle „Software & Updates“ aus.
2. Quellen anzeigen: Im Reiter „Ubuntu-Software“ seht ihr die wichtigsten Ubuntu-Repositories (Main, Universe, Restricted, Multiverse).
3. Zusätzliche Repositories: Unter dem Reiter „Andere Software“ könnt ihr PPAs und externe Repositories sehen.
4. Aktualisieren und ändern: Ihr könnt hier Quellen aktivieren, deaktivieren oder neue hinzufügen. Achtet darauf, dass die Quellen korrekt sind und mit euer Ubuntu-Version kompatibel.

Manuell über die Datei /etc/apt/sources.list

Wie bei Linux Mint könnt ihr auch in Ubuntu die Paketquellen direkt bearbeiten:

1. Öffnet das Terminal: Strg + Alt + T
2. Bearbeitet die Quellenliste:

   sudo nano /etc/apt/sources.list

3. Überprüft die Einträge: Achte darauf, dass keine veralteten oder ungültigen Repositories eingetragen sind. Achte auch darauf, dass ihr das richtige Repository für eure Ubuntu-Version verwendet.

Paketquellen prüfen in Debian

Debian geht etwas konservativer mit Repositories um und bietet eine stabilere Basis:

Manuell über die Datei /etc/apt/sources.list

Debian bietet standardmäßig keine GUI für die Verwaltung der Paketquellen, daher erfolgt die Überprüfung meist über das Terminal:

1. Öffnet das Terminal: Strg + Alt + T
2. Bearbeitet die Quellenliste:

   sudo nano /etc/apt/sources.list

3. Prüft die Einträge: In der Regel enthält die Datei nur offizielle Debian-Repositories. Überprüft, ob sie mit eurer Debian-Version (z.B. stable, testing, unstable) übereinstimmen.

Überprüft die zusätzlichen Quellen im Verzeichnis /etc/apt/sources.list.d/

Linux kann zusätzliche Quellen über Dateien im Verzeichnis /etc/apt/sources.list.d/ verwalten:

1. Liste der Dateien anzeigen:

   ls /etc/apt/sources.list.d/

2. Bearbeitet eine Datei: Wenn ihr eine bestimmte Quelle überprüfen möchtet, öffnet die entsprechende Datei:

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

Allgemeine Tipps zur Überprüfung der Paketquellen

• Vertrauenswürdigkeit: Verwendet nur Repositories, denen ihr vertraut, um Sicherheitsrisiken zu vermeiden. Nehmt keine Repos aus skurillen Foren oder von unbekannten Blogs auf.
• Korrektheit: Stellt sicher, dass die Repositories zu eurer spezifischen Version der Distribution passen (z.B. Debian - Bookworm/Bullseye, Ubuntu - jammy/noble).
• Aktualität: Prüft regelmäßig, ob eure Paketquellen aktuell sind und zu eurer Version der Distribution passen.

Durch regelmäßige Überprüfung und Pflege der Paketquellen stellt ihr sicher, dass euer System stets auf dem neuesten Stand und sicher bleibt.

Fazit

Mit diesem umfassenden Leitfaden habt ihr nun das nötige Wissen, um euer Linux Mint-, Debian- oder Ubuntu-System sicher und effektiv zu aktualisieren. Auch wenn das Thema "Updates" für Linux-Neulinge anfangs einschüchternd wirken kann, solltet ihr keine Angst davor haben. Der Update-Prozess ist gut dokumentiert, und die Systeme bieten euch sowohl grafische Oberflächen als auch einfache Terminal-Befehle, um den Prozess Schritt für Schritt durchzuführen. Mit den beschriebenen Methoden könnt ihr sicherstellen, dass euer System stets auf dem neuesten Stand bleibt, was nicht nur für die Sicherheit wichtig ist, sondern auch für die allgemeine Stabilität und Leistung eures Rechners. Selbst wenn mal ein Problem auftauchen sollte, habt ihr jetzt die Werkzeuge und das Verständnis, um es zu lösen. Also keine Sorge – mit etwas Übung wird das Aktualisieren eures Systems zur Routine, die euch ein zuverlässiges und sicheres Linux-Erlebnis garantiert.

Wollt ihr ein Linux System erstmal kennen lernen? Installiert euch eine Linux VM auf eurem bestehenden Windows System mit Hilfe dieses Artikels!

Noch kein Linux auf dem Rechner? Updates sind der einfache Teil. Wenn ihr Linux zuerst anschauen wollt, startet Linux online ausprobieren im Browser, ganz ohne Installation. Und wenn ihr das Einrichten überspringen möchtet: wir liefern Notebooks mit Linux vorinstalliert, die Distribution wählt ihr bei der Bestellung.

The post Wie update ich mein Linux System richtig appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Vorbereitungen

Die manuelle Methode zur Übertragung eines Apple/iCloud Kalenders auf ein Android Phone besteht darin, den Apple Kalender zu teilen und ihn in einen kompatiblen Android Kalender zu importieren. Wir bedienen unser dafür einer FOSS App von F-Droid, welche .ics Kalender importieren kann.

Ladet euch dafür die App Fossify Kalender herunter und installiert sie auf eurem Android Phone.

iPhone Kalender exportieren

Öffnet den Apple Kalender. Ihr könnt den iCloud/Apple Kalender öffnen, indem ihr https://www.icloud.com/calendar/ besucht.

Fahrt mit der Maus über den Apple Kalender, den ihr auf euer Android importieren möchtet. Die Kalender befinden sich in der Seitenleiste auf der linken Seite, unter dem Kalenderbereich.

Klickt auf das Profilbild-Symbol rechts neben dem Apple Kalender. Nachdem ihr auf das Symbol geklickt haben, wird ein Modal mit dem Titel "Kalenderfreigabe" angezeigt.

Schaltet den Schalter für den Öffentlichen Kalender ein. Dadurch wird der Apple Kalender öffentlich gemacht und es wird eine neue Webcal-URL generiert.

Kopiert die URL der Webcal, die generiert wurde. Ihr könnt den Link kopieren, indem ihr auf die von Apple Calendar bereitgestellte Schaltfläche "Kopieren" klickt.

Eine URL erscheint. Kopiert diese in eine neue Browser-Adresszeile und ändert den Adressteil webcal in http um. Surft dann die Adresse an. Euer Browser wird nun eine Datei herunterladen. Diese enthält eure Kalendereinträge. Speichert die Datei auf eurem Computer und fügt dem Dateinamen die Endung .ics hinzu, indem ihr die Datei einfach umbenennt.

Auf Android Kalender importieren

Öffnet die App Fossify Kalender. Geht mit dem Zahnrad Symbol in der oberen Leiste auf die Einstellungen:

Scrollt danach nach unten, und klickt auf Termine aus .ics Datei importieren:

Fertig! Eure Termine sind nun auf euer Android Smartphone importiert und sollten auch in eueren anderen Kalender Apps wie ETAR zur Verfügung stehen.

Kalender in die Nextcloud importieren

Nutzt ihr die Nextcloud für die zentrale Verwaltung eurer Termine, ist es sinnvoll, diesen Kalender direkt in eure Nextcloud zu importieren. Öffnet dazu die Kalender App der Nextcloud in eurem Browser, und klickt in der linken Leisten auf Einstellungen, und danach auf Kalender importieren:

Stellt sicher, dass ihr den neuen Kalender auch in der App DAVx5 synchronisiert:

Stelt sicher, dass die jeweilige App, die den Nextcloud CalDAV Kalender verwendet, auch den neu hinzugefügten Kalender inkludiert. Eine Anleitung um Kalender Apps mit der Nextcloud zu synchronisieren findet ihr auch hier.

Fazit

Nun haben wir eine weitere Hürde überwunden, und auch iPhone Nutzer, die eine Menge Termine über den Apple Kalender verwaltet haben, können mit einem Problem weniger erfolgreich migrieren oder ihre Migration planen. Die Nutzung von OpenSource Apps erlaubt später eine viele einfachere und schnellere Migration von persönlichen Kalender auf andere Android Phones. Mit der App Fossify Kalender könnt ihr auch jederzeit schnell und bequem vorhandene Kalender wieder exportieren.

The post iPhone Kalender auf Android oder in die Nextcloud übertragen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Ein Wechsel von Windows zu Linux kann am Anfang ganz schön verwirrend sein, aber keine Sorge, ich helfe euch in diesem Beitrag dabei, den Überblick zu behalten. Hier ist ein Einsteiger-Leitfaden, der die wichtigsten Unterschiede zwischen Windows und Linux hervorhebt und erklärt euch den Umstieg in einem einfachen und verständlichen Worten.

Zusammen in diesem Tutorial zeigen wir euch, was auf euch zukommt, solltet ihr den Wechsel in die freiheitlich Welt von Linux und Co wirklich wagen. Zusammen schauen wir uns Tipps für den Einsteig, Kosten und Lizenzen, Betriebssystemstruktur und Grundkenntnisse an. Ausserdem betrachten wir die Themen Sicherheit und Privatsphäre.

Windows 10 ist am Ende – jetzt ist der ideale Zeitpunkt für Linux

Falls ihr diesen Leitfaden gerade lest, hat das vermutlich einen konkreten Anlass: Der Support für Windows 10 ist am 14. Oktober 2025 ausgelaufen. Microsoft liefert seither keine kostenlosen Sicherheitsupdates mehr – euer System funktioniert zwar weiter, wird aber mit jeder neu entdeckten Sicherheitslücke angreifbarer. Genau deshalb suchen aktuell so viele Leute nach einer Alternative.

Microsofts Notlösung, das Extended Security Updates (ESU)-Programm, verschiebt das Problem nur: Es liefert privaten Nutzern noch bis maximal 13. Oktober 2026 reine Sicherheitsupdates (gegen Anmeldung, Microsoft-Rewards-Punkte oder eine einmalige Gebühr) – keine neuen Funktionen, keinen echten Support. Danach ist endgültig Schluss.

Der von Microsoft vorgesehene Ausweg heisst Windows 11 – doch der hat einen Haken: Die strengen Hardware-Anforderungen (TPM 2.0, Secure Boot, relativ neue CPU) sperren Millionen völlig funktionstüchtiger PCs aus. Diese Geräte landen im schlimmsten Fall im Elektroschrott, obwohl sie technisch noch jahrelang einwandfrei laufen würden.

Und genau hier kommt Linux ins Spiel: Es ist kostenlos, erhält fortlaufend Sicherheitsupdates und haucht gerade älterer Hardware neues Leben ein, statt sie künstlich auszumustern. Wer also vor der Wahl steht – neuer PC, kostenpflichtiges ESU oder Umstieg – findet in Linux die nachhaltigste Antwort. Unsicher, welche Distribution zu euch passt? In unserem Vergleich Welches Linux-Betriebssystem? stellen wir die wichtigsten Systeme vor, und der interaktive Linux-Finder führt euch in wenigen Klicks zur passenden Wahl – Linux Mint gilt dabei als der Klassiker für Windows-Umsteiger. Den Rest dieses Leitfadens könnt ihr dann ganz entspannt durchgehen.

Tipps für den Einstieg

Lasst uns ein Paar Tipps für den Einstieg anschauen. Dies soll euch erstmal helfen, die richtige Distro zu finden, die Grundlagen kennen zu lernen und euch zeigen wo ihr gegebenfalls Hilfe bekommen könnt.

• Wählt eine benutzerfreundliche Distribution: Für Anfänger sind Ubuntu beziehungsweise Kubuntu mit KDE Desktop, oder Linux Mint empfehlenswert, da sie sehr intuitiv sind.
• Lerne die Grundlagen des Terminals: Ein paar grundlegende Befehle zu kennen, wird euch enorm helfen, muss aber nicht unbedingt sein.
• Lern die wichtigsten Begriffe in der Welt von Linux: damit ihr euch zurecht findet, bei Support von der Community, oder wenn ihr Artikel zu Linux lest.
• Nutzt die Community: Wenn ihr nicht weiterkommt, zögert nicht, in Foren oder auf Plattformen wie Reddit nach Hilfe zu fragen.
• Testet Linux vorher auf einer virtuellen Maschine: ja, ihr könnt Linux auch in einer virtuellen Maschine testen, die ihr auf eurem Windows Rechner ausführen könnt

Dazu haben wir auch Beiträge verfasst, einmal zu den wichtigsten Linux Distros und ihren Eigenschaften, und welche Begriffe es zum kennen lernen gibt, damit ihr euch in der Welt von Linux von Anfang an besser zurecht findet. Und auch, wie man Linux in einer virtuellen Maschine auf Windows testet:

Community Foren

Hier zudem die bekanntesten und grössten Community Foren zu Linux allgemein, und dazu zu Linux Mint und Ubuntu:

https://www.linuxforen.de/forums/index.php --> deutsches Forum allgemein um das Thema Linux

https://www.linuxmintusers.de/index.php --> grosses Linux Mint spezifisches Forum

https://forum.ubuntuusers.de --> grosses Ubuntu basiertes Forum für Distros wie Ubuntu / Kubuntu

Kosten und Lizenzen

Der Umstieg von Windows auf Linux bringt nicht nur sicherheitstechnische und datenschutzrechtliche Vorteile mit sich, sondern auch Unterschiede in Bezug auf Kosten und Lizenzen. Hier ist ein kurzer Überblick über die wichtigsten Aspekte:

Kosten

Windows:

• Windows ist in der Regel kostenpflichtig. Die Lizenzen für verschiedene Versionen (Home, Pro, Enterprise) müssen gekauft werden.
• Zusätzliche Software und Anwendungen, wie Microsoft Office, erfordern ebenfalls separate Lizenzen, die zusätzliche Kosten verursachen.

Linux:

• Linux-Distributionen sind in der Regel kostenlos. Man kann sie kostenlos herunterladen und nutzen.
• Es gibt auch kostenpflichtige Versionen, die zusätzlichen Support und professionelle Dienstleistungen bieten, wie beispielsweise Red Hat Enterprise Linux oder SUSE Linux Enterprise, aber die meisten gängigen Distributionen (wie Ubuntu, Fedora, Debian) sind kostenlos.

Lizenzen

Windows:

• Windows verwendet proprietäre Lizenzen. Das bedeutet, dass der Quellcode nicht öffentlich zugänglich ist und Benutzer Einschränkungen hinsichtlich der Nutzung, Modifikation und Verbreitung des Betriebssystems haben.
• Benutzer müssen die Lizenzbedingungen akzeptieren, die unter anderem vorschreiben, dass die Software nur auf einer bestimmten Anzahl von Geräten installiert werden darf.

Linux:

• Linux basiert auf Open-Source-Lizenzen, hauptsächlich der GNU General Public License (GPL). Diese Lizenzen erlauben es Benutzern, den Quellcode zu betrachten, zu modifizieren und weiterzuverbreiten.
• Dadurch haben Benutzer mehr Freiheit und Kontrolle über das Betriebssystem und können es nach ihren Bedürfnissen anpassen.

Der Wechsel zu Linux kann also nicht nur Kosten sparen, sondern bietet auch mehr Flexibilität und Freiheit durch Open-Source-Lizenzen. Dies ist besonders attraktiv für diejenigen, die ihre Software anpassen und sich nicht an die Einschränkungen proprietärer Software binden möchten.

Betriebssystem-Struktur Benutzeroberfläche und Aufbau

Wir erklären euch die Struktur und den Aufbau der Benutzeroberfläche (GUI) von Windows und Linux im Detail und vergleichen diese zueinander.

Desktop-Umgebung

Windows:

• Desktop: Der zentrale Ausgangspunkt mit Verknüpfungen zu Dateien, Ordnern und Anwendungen. Hintergrundbild und Themes können angepasst werden.
• Taskleiste: Am unteren Bildschirmrand mit Startknopf, Symbolen für geöffnete und angeheftete Programme, Benachrichtigungsfeld und Uhr.
• Startmenü: Zugang zu installierten Anwendungen, Systemeinstellungen und zuletzt verwendeten Dateien. Anpassbar für häufig verwendete Programme.

Linux:

• Desktop (z.B. GNOME, KDE Plasma, XFCE): Bietet verschiedene Umgebungen. GNOME hat eine Aktivitäten-Übersicht, KDE Plasma ist hochgradig anpassbar, XFCE ist ressourcenschonend.
• Panel/Taskleiste: Ähnlich wie bei Windows, enthält Anwendungsstartleiste, Uhr und Systembenachrichtigungen. In KDE Plasma können Widgets hinzugefügt werden.
• Anwendungsmenü: Entspricht dem Startmenü, je nach Desktop-Umgebung unterschiedlich gestaltet (z.B. GNOME hat ein einfaches Menü, KDE ein umfassenderes).

Fenster-Management

Windows:

• Fenster: Anwendungen werden in Fenstern geöffnet, die verschoben, in der Größe verändert, minimiert und maximiert werden können. Titelleiste mit Schließen-, Minimieren- und Maximieren-Buttons.
• Snap-Feature: Fenster lassen sich durch Ziehen an den Bildschirmrand positionieren (z.B. zwei Fenster nebeneinander).

Linux:

• Fenster: Ähnlich wie bei Windows, mit verschiebbaren, größenveränderbaren, minimier- und maximierbaren Fenstern. Unterschiedliche Fenster-Manager (z.B. Mutter für GNOME, KWin für KDE).
• Workspaces: Unterstützt virtuelle Arbeitsbereiche, die mehrere Desktops für verschiedene Aufgaben ermöglichen.

Dateimanager

Windows:

• Explorer: Standard-Tool zum Durchsuchen und Verwalten von Dateien und Ordnern. Navigationsfenster links mit schnellen Zugriffen und Favoriten, rechts die Inhalte des ausgewählten Ordners.

Linux:

• Nautilus (GNOME Files): Standard-Dateimanager in GNOME mit einfacher Benutzeroberfläche.
• Dolphin: Standard-Dateimanager in KDE Plasma mit erweiterten Funktionen wie Split-View und umfassenden Anpassungsoptionen.

Systemeinstellungen

Windows:

• Einstellungen: Zugriff über Startmenü oder Benachrichtigungsfeld. Unterteilt in Kategorien wie System, Geräte, Netzwerk & Internet, Personalisierung und Konten.

Linux:

• GNOME Settings: Konsolidierte Einstellungen in einer einfachen, leicht navigierbaren Oberfläche. Kategorien wie Netzwerk, Bluetooth, Energieverwaltung und Barrierefreiheit.
• KDE System Settings: Umfassendes Kontrollzentrum mit zahlreichen Anpassungsoptionen. Kategorien umfassen Erscheinungsbild, Hardware, Netzwerk und Benutzerkonten.

Windows und Linux bieten beide robuste und vielseitige Benutzeroberflächen, jedoch mit unterschiedlichen Philosophien. Windows zielt auf eine konsistente und benutzerfreundliche Erfahrung mit wenig Anpassungsbedarf. Linux hingegen bietet eine große Auswahl an Desktop-Umgebungen, die unterschiedlich anpassbar sind, um den verschiedenen Bedürfnissen und Vorlieben der Benutzer gerecht zu werden. Beide Systeme haben ihre eigenen Stärken und sind je nach Nutzungsszenario und Benutzerpräferenz geeignet.

Ein Beitrag der sich mit der Benutzer- und der Rechteverwaltung unter Linux befasst, findet ihr hier:

Datei-Endungen Windows vs Linux

Wir schauen uns in folgenden Artikel mal die Datei-Endung an, und vergleichen diese mit Windows. Dies ist wichtig damit ihr wisst, was ihr mit bestimmten Dateien tun könnt, oder müsst.

Standard-Dateisysteme von Linux und Microsoft und ihre Kompatibilität

Beim Umstieg von Windows auf Linux oder beim parallelen Einsatz beider Betriebssysteme spielt die Kompatibilität der Dateisysteme eine wichtige Rolle. Linux nutzt standardmäßig das ext4-Dateisystem, während Windows auf NTFS setzt. Diese unterschiedlichen Dateisysteme haben spezifische Stärken und Eigenschaften, die für ihre jeweilige Plattform optimiert sind. Um nahtlos zwischen beiden Systemen arbeiten zu können und Daten problemlos auszutauschen, gibt es jedoch verschiedene Lösungen und gemeinsame Dateisysteme wie exFAT, die von beiden Betriebssystemen unterstützt werden.

Linux:

• Das standardmäßige Dateisystem für Linux ist ext4 (Fourth Extended Filesystem). Es bietet hohe Leistung, Zuverlässigkeit und unterstützt große Dateien und Festplatten.
• Andere gängige Dateisysteme unter Linux sind Btrfs, XFS und ZFS, die je nach Bedarf verschiedene Vorteile wie Snapshots, Selbstheilung und bessere Skalierbarkeit bieten.

Windows:

• Windows verwendet standardmäßig NTFS (New Technology File System). Es bietet robuste Leistung, dafür weniger Sicherheit und ist für große Festplatten und Dateien ausgelegt.
• Für Wechseldatenträger und ältere Systeme wird auch FAT32 und exFAT verwendet, wobei exFAT für größere Dateien und Partitionen besser geeignet ist.

Kompatibilität:

• Linux und NTFS: Linux kann NTFS-Partitionen lesen und schreiben, jedoch mit Hilfe von Treibern wie ntfs-3g, die in den meisten Distributionen vorinstalliert sind.
• Windows und ext4: Windows unterstützt ext4 nicht nativ. Um auf ext4-Partitionen zuzugreifen, müssen spezielle Softwarelösungen wie Ext2Fsd oder Ext2Read verwendet werden. Windows kann also einen USB Stick oder ein Datenträger, der mit ext4 formatiert wurden ist, nicht lesen.
• Gemeinsame Dateisysteme: Für den Austausch von Dateien zwischen Windows und Linux wird oft NTFS, exFAT oder FAT32 verwendet, da beide Betriebssysteme diese Dateisysteme nativ unterstützen.

Zusammengefasst bieten Linux und Windows unterschiedliche Dateisysteme, aber es gibt Wege, um ihre Kompatibilität zu gewährleisten, vor allem durch zusätzliche Software und die Verwendung von gemeinsam unterstützten Dateisystemen wie exFAT. Ein Beitrag der sich mit dem Thema Dateien Systeme befasst, finder ihr hier:

Software-Verfügbarkeit und Kompatibilität

Auf Windows seid ihr euch es gewöhnt, entweder Apps aus dem Market Store herunterzuladen und zu installieren, oder ihr installiert euch Software, in dem ihr .exe, oder .msi Dateien herunterladet. Hier werdet ihr meisst durch einen Installer geleitet, der euch auch ermöglicht Software an verschiedenen Pfaden eures Betriebssystems zu installieren. Dies läuft auf Linux mehr oder weniger ähnlich. Die meissten Distro haben integrierte Software Centren, in denen ihr übersichtlich in einer Oberfläche allmöglichen Apps findet. Software die nicht in den Software Centren integriert sind, findet ihr dann wiederrum beim Herausgeber der Software auf deren Webpage. Ein Installer wie zum Beispiel qApt installieren euch die Software schnell auf eurem Linux System. Im gegensatz zu Windows, werden Linux Programme zum grössten teil fest an bestimmte Stellen im Betriebssystem installiert

Wo finde ich Software für Linux und wie installiere ich diese

In den Linux Software Centren

Linux hat im Vergleich zu seinen Anfangstagen einen langen Weg zurückgelegt, was die Verfügbarkeit von Software angeht. Viele Linux-Distributionen bieten heute eine benutzerfreundliche Erfahrung, die stark an das gewohnte Vorgehen unter Windows angelehnt ist, mitlerweile meiner Meinung heutzutage sogar besser ist.

• Software Center: Ubuntu, Linux Mint und viele andere Distributionen verfügen über sogenannte "Software Center", die ähnlich funktionieren wie der App Store auf macOS oder der Microsoft Store auf Windows. Diese Software Center bieten eine grafische Schnittstelle, um Software zu suchen, zu installieren und zu verwalten. Du kannst nach Anwendungen kategorisiert suchen, Bewertungen und Beschreibungen lesen und die Software mit nur wenigen Klicks installieren.

Vorteile des Software Centers

• Einfache Installation: Software aus dem Software Center zu installieren, ist einfach und sicher, da alle Anwendungen von der Community oder den Distributions-Maintainern überprüft wurden.
• Automatische Updates: Anwendungen, die aus dem Software Center installiert werden, erhalten automatische Updates. Das bedeutet, dass ihr immer die neuesten Features und Sicherheitspatches erhaltet, ohne dass ihr manuell nach Updates suchen müsst.

Im Internet

Wie bei Windows findet ihr wichtige Software meisst beim Hersteller direkt zum download. Wir klären in den nachfolgenden Abschnitten, wie ihr die richtige Software für euer Linux System auswählt.

Wie wähle ich den richtigen Download von Software aus

Wenn ein Softwarehersteller verschiedene Linux-Versionen eines Programms zum Download anbietet, kann es manchmal verwirrend sein, die richtige auszuwählen. Hier ein einfaches Beispiel, das erklärt, wie ihr vorgehen solltet, um die passende Version für euer System auszuwählen:

Schritt 1: Kennt eure Systemarchitektur

Zuerst müsst ihr herausfinden, welche Architektur euer Prozessor verwendet. Die meisten modernen Computer verwenden 64-bit Prozessoren (auch bekannt als x64 oder amd64). Ältere oder sehr leichte Systeme könnten noch eine 32-bit Architektur verwenden ( Zum Beispiel ARM Geräte wie der Raspberry Pi 4 in älteren Distros)

• So findet ihr es heraus unter Linux:
  Öffnet ein Terminal und gebt den Befehl uname -m ein.
• Wenn die Ausgabe x86_64 oder amd64 ist, läuft euer System auf einer 64-bit Architektur.
• Eine Ausgabe wie i686 oder i386 bedeutet, dass es ein 32-bit System ist.

Schritt 2: Wählt die passende Distribution

Hersteller bieten oft spezielle Pakete für verschiedene Linux-Distributionen an, weil sich die mitgelieferten Bibliotheken und Abhängigkeiten unterscheiden können. Zu den gängigen Distributionen gehören:

• Ubuntu/Debian: Diese verwenden .deb Pakete.
• Fedora/Red Hat: Diese verwenden .rpm Pakete.
• Arch Linux: Diese verwenden Pakete aus dem Arch User Repository (AUR) oder tarballs.

Schritt 3: Überprüft die Version der Distribution

Einige Anbieter bieten Downloads speziell für ältere oder neuere Versionen einer Distribution an. Es ist wichtig, die Version eurer Installation zu kennen, um Kompatibilitätsprobleme zu vermeiden.

• So findet ihr die Version eurer Distribution heraus:
  Für Ubuntu oder Debian basierte Systeme, öffnet das Terminal und gebt lsb_release -a ein.
  Für Fedora oder andere RPM-basierte Systeme, probiert cat /etc/fedora-release oder cat /etc/redhat-release.

Schritt 4: Wählt das richtige Paket

Basierend auf euren Informationen (Architektur, Distribution, Version), wählt das passende Paket auf der Download-Seite:

• Beispiel: Ihr habt ein 64-bit Ubuntu 20.04 System.
• Wählt ein Paket, das als Programmname_amd64.deb für Ubuntu 20.04 gekennzeichnet ist.

Schritt 5: Installation von DEB-Paketen

Trotz der Bequemlichkeit des Software Centers gibt es eben manchmal Situationen, in denen ihr Software installieren musst, die dort nicht verfügbar ist. Viele Programme für Debian-basierte Distributionen wie Ubuntu oder Mint werden als DEB-Pakete bereitgestellt. Hier ist, wie man sie installiert:

1. Herunterladen: Ladet das DEB-Paket von der offiziellen Website des Anbieters herunter. Achtet darauf, dass ihr wie beschrieben die richtige Version für eure Distribution und Architektur wählt.
2. Installation via GUI: Die meisten Linux-Distributionen ermöglichen es euch, DEB-Dateien durch einen Doppelklick zu installieren. Dies öffnet ein Fenster, das ähnlich wie ein Installationsassistent unter Windows funktioniert, wo ihr den Installationsprozess starten könnt.
3. Installation via Terminal: Falls ihr die Installation lieber über das Terminal ausführen möchtet, könnt ihr das Paket mit dem Befehl dpkg installieren. Öffnet ein Terminalfenster, navigiert zu dem Verzeichnis, welches die heruntergeladene DEB-Datei enthält, und führe folgenden Befehl aus:

   sudo dpkg -i paketname.deb

Falls Abhängigkeiten fehlen sollten, könnt ihr diese nach der Installation des DEB-Pakets mit dem folgenden Befehl installieren. In der Regel ist das aber kaum der Fall.

   sudo apt-get install -f

Weitere Installationsmethoden

Besucht hier für weitere Informationen unseren Beitrag zu den verschiedensten Installationsmethoden für Linux Debian, Ubuntu und Mint Systeme. Hier erklären wir euch was deb, snaps, flatpaks und AppImages genauer sind:

Wartung und Management

Die Wartung eures Linux-Systems ist dank der integrierten Tools und des Software Centers relativ unkompliziert. Regelmäßige Updates helfen nicht nur dabei, deine Software auf dem neuesten Stand zu halten, sondern auch Sicherheitslücken schnell zu schließen. Es ist ratsam, regelmäßig das Update-Management eurer Distribution zu nutzen, um sicherzustellen, dass euer System und eure Anwendungen optimal laufen.

Durch diese Strukturen ist Linux heute zugänglicher denn je, und die Notwendigkeit, die Kommandozeile für alltägliche Aufgaben zu nutzen, hat stark abgenommen. Das macht Linux zu einer attraktiven Alternative für Nutzer, die von Windows umsteigen möchten.

Updates

• Windows: Updates werden automatisch heruntergeladen und installiert, manchmal zu Zeiten, die nicht immer ideal sind. Das System kümmert sich im Hintergrund um die meisten Sicherheits- und Wartungsarbeiten.
• Linux: Ihr habt mehr Kontrolle über Updates. Diese können über das Terminal oder eine Update-Verwaltung gesteuert werden. Ihr entscheidet, wann und was aktualisiert wird.

Softwarealternativen für Windows Programme

Wenn ihr von Windows auf Linux umsteigt, gibt es viele gängige Softwarealternativen, die ähnliche Funktionen bieten wie euch bekannte Programme. Hier sind einige wichtige Beispiele:

Office-Paket

Auf Windows ist Microsoft Office die Standard-Office-Suite. Für Linux gibt es LibreOffice oder Apache OpenOffice als Alternative. Beide bieten Textverarbeitung (Writer), Tabellenkalkulation (Calc), Präsentationen (Impress) und mehr. Schaut im verlinkten Beitrag vorbei zu weitere Infos zu Office auf Linux:

Webbrowser

Microsoft Edge ist der Standardbrowser auf Windows. Auf Linux könnt ihr Firefox nutzen, einen leistungsstarken, sicheren und privatsphärenfreundlichen Browser. Alternativ gibt es auch Chromium, die Open-Source-Basis von Google Chrome oder Brave, und den Tor Browser als Privacy optimierte Browser Varianten.

Bildbearbeitung

Adobe Photoshop ist auf Windows weit verbreitet. GIMP (GNU Image Manipulation Program) ist die entsprechende Alternative auf Linux. GIMP bietet viele Funktionen für die Bildbearbeitung und ist sehr leistungsfähig. Es gibt sehr viel Fachbücher und Videos auf Youtube oder ähnlichen Plattformen, wie man mit GIMP ähnlich vielfältig arbeitet, wie mit Adobe Photoshop.

E-Mail-Client

Microsoft Outlook ist der gängige E-Mail-Client auf Windows. Auf Linux könnt ihr Thunderbird verwenden, einen flexiblen E-Mail-Client von Mozilla mit umfangreichen Erweiterungsmöglichkeiten. Wie man seite Outlook Mails in Thunderbird importiert, erfahrt ihr im verlinkten Beitrag. Falls ihr erstmal mit Thunderbird überfordert seid, könnt ihr eure Mails auch weiterhin bearbeiten, indem ihr die Browserbasierten Logins eures Email Anbieters verwendet.

Mediaplayer

Windows Media Player ist der Standardmediaplayer auf Windows. Auf Linux bietet VLC Media Player eine ausgezeichnete Alternative, die eine breite Palette an Video- und Audioformaten unterstützt. Er ist dem Funktionsumfang vom Windows Media Play deutlich überlegen.

Texteditor/IDE

Notepad++ ist ein beliebter Texteditor auf Windows. Für Linux gibt es zum Beispiel Kate, einen leistungsstarken, erweiterbaren Code-Editor von KDE. Alternativ könnt du auch Sublime Text verwenden, einen beliebten Editor für Code, Markup und Prosa.

Dateimanager

Der Windows Explorer ist der Standard-Dateimanager auf Windows. Auf Linux könnt ihe Nautilus verwenden, wenn ihr GNOME nutzt, oder Dolphin, wenn ihr KDE bevorzugt. Beide bieten eine benutzerfreundliche Datei- und Verzeichnisverwaltung. Auf Linux sind per Standard natürlich bereits entsprechende Dateien-Explorer installiert.

Systemwartung

CCleaner ist ein bekanntes Wartungstool auf Windows. Auf Linux gibt es BleachBit, das unnötige Dateien reinigt und die Privatsphäre schützt.

Datensicherung

Acronis True Image ist ein bekanntes Backup-Tool auf Windows. Auf Linux gibt es Deja Dup oder Timeshift, eine einfache und automatisierte Datensicherungslösung.

Virtualisierung

VMware und VirtualBox sind gängige Virtualisierungslösungen auf Windows. VirtualBox ist auch auf Linux verfügbar und bietet eine kostenlose Möglichkeit, Gast-Betriebssysteme zu betreiben.

Diese Alternativen bieten oft ähnliche Funktionalitäten und sind in der Regel kostenlos. Sie können auf den meisten Linux-Distributionen installiert und verwendet werden, sodass der Umstieg von Windows auf Linux reibungslos verläuft. Im Beitrag unten findet ihr weitere Alternativen in einem ausführlichen Artikel:

Drucken und Scannen

Drucken und Scannen unter Linux: Was Umsteiger erwartet

Wenn ihr von Windows auf Linux umsteigt, werdet ihr feststellen, dass das Drucken und Scannen etwas anders funktioniert. Während es auf Windows oft spezialisierte Software von Druckerherstellern gibt, die installiert werden muss, ist dies bei Linux nicht immer der Fall. Hier ist, was euch erwartet und wie ihr damit umgehen könnt.

Drucken unter Linux

Kompatibilität:

• Die besten Chancen, dass euer Drucker funktioniert, ist das Gerät über das Netzwerk zu verbinden. Netzwerkdrucker und Drucker mit integriertem Wi-Fi funktionieren in der Regel problemlos.
• Probleme gibt es manchmal , fall Drucker nur via USB verbunden werden können.
• Die meisten modernen Drucker funktionieren gut mit Linux, insbesondere wenn sie die gängigen Druckerprotokolle wie PCL oder PostScript unterstützen.
• HP-Drucker sind besonders gut unterstützt dank des HP Linux Imaging and Printing (HPLIP) Projekts, das umfassende Treiber und Software bereitstellt.
• Brother gehört zu den Herstellern, die ebenso per Default ohne Installation von Treiber auf Linux funktioniert.

Installation:

• Linux nutzt das Common Unix Printing System (CUPS) als Druckerverwaltung. CUPS bietet eine webbasierte Schnittstelle, über die ihr Drucker hinzufügen, konfigurieren und verwalten könnt.
• Viele Drucker werden automatisch erkannt und eingerichtet, sobald sie an das Netzwerk angeschlossen werden.
• Bei HP Druckern müssen teilweise noch bestimmte Treiber installiert werden. Linux Mint beinhaltet die meissten Drucker Treiber von Haus aus.

Einschränkungen:

• Einige spezialisierte Funktionen, die durch herstellerspezifische Windows-Software angeboten werden (z.B. erweiterte Tintenstandsanzeigen oder spezielle Druckmodi), sind möglicherweise nicht verfügbar.
• Ältere Drucker oder solche, die auf proprietäre Treiber angewiesen sind, können Schwierigkeiten bereiten oder überhaupt nicht funktionieren.

Scannen unter Linux

Kompatibilität:

• Die meisten Scanner und Multifunktionsdrucker werden von Linux gut unterstützt, insbesondere solche, die SANE (Scanner Access Now Easy) kompatibel sind.
• Auch hier sind HP-Geräte gut unterstützt durch das HPLIP-Projekt.

Installation:

• SANE ist das Backend für Scanner-Unterstützung unter Linux und funktioniert mit vielen gängigen Geräten.
• Simple Scan, Skanlite und XSane sind benutzerfreundliche Frontend-Anwendungen, die das Scannen unter Linux erleichtern.

Einschränkungen:

• Ähnlich wie beim Drucken können spezialisierte Funktionen, die durch herstellerspezifische Software angeboten werden (z.B. erweiterte Scan-Modi oder Dokumentenverwaltung), möglicherweise fehlen.
• Proprietäre Scanner-Treiber sind selten, was die Unterstützung für einige Geräte einschränken kann.

Für die meisten Benutzer ist das Drucken und Scannen unter Linux nicht umständlich. Moderne Drucker und Scanner werden oft automatisch erkannt und konfiguriert. Die Nutzung von CUPS und SANE erleichtert den Prozess erheblich. Dennoch gibt es Ausnahmen, insbesondere bei älteren oder spezialisierten Geräten, bei denen die Unterstützung eingeschränkt sein kann. In solchen Fällen kann es notwendig sein, nach spezifischen Linux-Treibern oder alternativen Lösungen zu suchen. Im Allgemeinen bieten jedoch die meisten gängigen Geräte eine gute Unterstützung und Integration in die Linux-Umgebung. Ein Artikel der sich mit dem Thema Scannen & Sane befasst, haben wir ebenfalls hier geschrieben:

Meine Software spinnt, oder startet nicht mehr

Wenn ihr auf Linux umsteigt, werdet ihr vielleicht feststellen, dass der Umgang mit Fehlern und Problemen in Apps ein wenig anders läuft als unter Windows. Eine der Stärken von Linux ist der effiziente Umgang mit Updates, die oft schnell und unkompliziert helfen, Fehler in Anwendungen zu beheben. Hier ist, was ihr tun könnt, wenn ihr auf Probleme stößt:

Schritt 1: Verwendet das Update-Center eurer Distribution

Fast jede Linux-Distribution hat ein zentrales Update-Center oder einen Paketmanager, der es euch leicht macht, eure installierte Software auf dem neuesten Stand zu halten. Hier sind ein paar Tipps dazu:

• Regelmäßige Updates: Unter Linux ist es besonders sinnvoll, eure Software regelmäßig zu aktualisieren. Linux-Updates sind nicht nur für die Sicherheit wichtig, sondern verbessern auch die Stabilität eurer Anwendungen und beheben häufig auftretende Fehler.
• Update-Center nutzen: Öffnet das Update-Center eurer Distribution (wie z.B. "Software Updater" in Ubuntu oder "Update Manager" in Mint). Diese Tools zeigen euch verfügbare Updates für euer System und eure Anwendungen. Sie können automatisch nach neuen Updates suchen und euch auffordern, diese zu installieren.
• Terminal-Befehle für Updates: Wenn ihr euch schon ein wenig mit dem Terminal vertraut gemacht habt, könnt ihr Updates auch direkt darüber installieren. Befehle wie sudo apt update und sudo apt upgrade (für basierend auf Debian-Distributionen) überprüfen und installieren verfügbare Updates.

Schritt 2: Fehler beheben, wenn Updates nicht helfen

Manchmal reicht ein einfaches Update nicht aus, um ein Problem zu lösen. Hier sind weitere Schritte, die ihr unternehmen könnt:

• Fehlerberichte und Logs: Überprüft die Fehlerlogs und -berichte, die oft Hinweise auf die Ursache des Problems geben. Ihr könnt Zugang zu diesen Logs über Tools wie System Log Viewer bekommen oder im Terminal mit Befehlen wie dmesg oder journalctl <Dienstname>.
• Community-Foren und Support nutzen: Nutzt die Linux-Community. Foren von Ubuntu, Fedora, oder spezifischen Anwendungen sind oft voll mit Nutzern, die ähnliche Probleme erlebt haben und Lösungen teilen. Links dazu habt ihr weiter oben erhalten.
• Reinstallation der App: Manchmal kann das Deinstallieren und erneute Installieren einer Anwendung Abhilfe schaffen. Das kann insbesondere bei schwerwiegenden Problemen oder korrupten Installationen nützlich sein.

Schritt 3: Backup-Strategie

• Regelmäßige Backups: Bevor ihr größere Updates oder Fehlerbehebungen durchführt, ist es klug, regelmäßig Backups eurer wichtigen Daten zu machen. Tools wie Deja Dup (für Ubuntu) oder Timeshift bieten einfache Möglichkeiten, eure Daten zu sichern.

Indem ihr regelmäßige Updates durchführt und aktiv an der Linux-Community teilnimmt, könnt ihr viele der gängigen Probleme effektiv vermeiden oder schnell lösen. Linux gibt euch viel Kontrolle, fordert aber auch, dass ihr proaktiv bleibt, besonders was die Wartung eures Systems angeht.

Hier 2 Beiträge, die euch Sicherungen eures Systems auf verschiedene Art und Weisen durchführen lässt:

Ich benötige unbedingt eine bestimmte Windows Software!

Für Anfänger, die von Windows auf Linux umsteigen und bestimmte Windows-Software weiter nutzen möchten (wie Steuererklärungstools), gibt es zwei praktikable Lösungen: WINE und Virtualisierung.

WINE

WINE (Wine Is Not an Emulator) ist eine Kompatibilitätsschicht, die es ermöglicht, Windows-Programme direkt unter Linux auszuführen. WINE übersetzt Windows-Systemaufrufe in Linux-äquivalente Aufrufe, sodass viele Windows-Anwendungen ohne die Notwendigkeit eines vollständigen Windows-Betriebssystems laufen können.

Vorteile:

• Performance: Da WINE keine virtuelle Maschine ist, läuft die Software oft schneller als in einer virtualisierten Umgebung.
• Einfachheit: Benutzer können Windows-Programme direkt aus ihrem Linux-Desktop heraus starten, ohne zwischen Betriebssystemen wechseln zu müssen.
• Kostenlos: WINE ist kostenlos und Open Source, was bedeutet, dass es ohne zusätzliche Kosten genutzt werden kann.

Nachteile:

• Kompatibilität: Nicht alle Windows-Programme laufen perfekt unter WINE. Einige Anwendungen können Fehler haben oder gar nicht starten.
• Konfiguration: Manchmal erfordert WINE zusätzliche Konfigurationen oder Anpassungen, um bestimmte Programme korrekt auszuführen.

Wie man WINE verwendet, haben wir euch in diesem Artikel zusammengefasst:

Virtualisierung

Virtualisierung ermöglicht es, ein vollständiges Windows-Betriebssystem innerhalb einer virtuellen Maschine (VM) unter Linux zu betreiben. Tools wie VirtualBox oder VMware erlauben es, Windows neben Linux zu installieren und auszuführen.

Vorteile:

• Kompatibilität: Eine virtuelle Maschine bietet eine nahezu vollständige Windows-Umgebung, sodass praktisch alle Windows-Anwendungen ohne Kompatibilitätsprobleme laufen.
• Isolierung: Anwendungen laufen in einer isolierten Umgebung, was das Risiko von Systemkonflikten oder Sicherheitsproblemen reduziert.

Nachteile:

• Ressourcenintensiv: Virtualisierte Umgebungen benötigen mehr Systemressourcen (CPU, RAM, Speicher), was auf weniger leistungsfähigen Computern zu Performance-Einbußen führen kann.
• Kosten: Eine Windows-Lizenz ist erforderlich, um Windows in einer VM zu installieren, was zusätzliche Kosten verursachen kann.

Einer der besten Möglichkeiten Windows Software unter Linux laufen zu lassen, ist sich eine günstige Windows 10 Lizenz zu kaufen, und diese in VirtualBox auf dem Linux zu betreiben. Windows 11 macht auf virtuellen Maschinen teilweise immer noch Probleme. Ein Artikel auf Englisch, findet ihr dazu hier:

https://itsfoss.com/install-windows-10-virtualbox-linux

Für Anfänger, die von Windows auf Linux umsteigen und spezifische Windows-Software weiterhin nutzen möchten, bieten WINE und Virtualisierung effektive Lösungen. WINE ist ideal für Benutzer, die leichte bis mittlere Anwendungen mit minimalem Ressourcenaufwand betreiben möchten, während Virtualisierung die beste Wahl für Anwendungen ist, die vollständige Kompatibilität und Leistung erfordern. Beide Ansätze ermöglichen es, die Vorteile von Linux zu genießen, ohne auf gewohnte Windows-Programme verzichten zu müssen.

Sicherheit vor Viren

Ein wesentlicher Vorteil von Linux gegenüber Windows ist seine erhöhte Sicherheit gegenüber Viren und Malware. Diese höhere Sicherheit beruht auf mehreren Faktoren.

Erstens, die Architektur von Linux ist von Grund auf sicherer gestaltet. In Linux sind Benutzer standardmäßig keine Administratoren (root). Sie arbeiten meist mit eingeschränkten Rechten, was bedeutet, dass selbst wenn ein Virus den Computer infiziert, er keine kritischen Systemdateien ohne spezielle Berechtigungen ändern kann. Bei Windows hingegen arbeiten viele Benutzer mit Administratorrechten, was Malware leichtes Spiel gibt, umfassenden Schaden anzurichten.

Zweitens, die Struktur der Software-Installation in Linux erhöht die Sicherheit erheblich. Software wird in der Regel aus offiziellen, zentralisierten Repositories installiert, die sorgfältig gepflegt und auf Sicherheit überprüft werden. Das reduziert die Wahrscheinlichkeit, dass Benutzer unwissentlich infizierte Software herunterladen und installieren. Im Gegensatz dazu ist es bei Windows üblich, Software aus verschiedenen Quellen im Internet herunterzuladen, was das Risiko erhöht, auf schädliche Software zu stoßen.

Drittens, die Vielfalt und Offenheit von Linux. Es gibt viele verschiedene Linux-Distributionen, und der Quellcode ist für jeden zugänglich. Diese Offenheit ermöglicht es der Gemeinschaft, Schwachstellen schnell zu entdecken und zu beheben. Darüber hinaus macht die Vielfalt der Distributionen es schwieriger für Malware, sich weit zu verbreiten, da ein Virus, der für eine spezifische Distribution entwickelt wurde, nicht notwendigerweise auf anderen Distributionen funktioniert.

Schließlich spielt auch die geringere Verbreitung von Linux eine Rolle. Da Linux auf Desktops weniger verbreitet ist als Windows, ist es ein weniger attraktives Ziel für Malware-Entwickler. Sie konzentrieren sich lieber auf Windows, da sie dort eine größere Anzahl potenzieller Opfer finden.

Zusammengefasst bieten die strengere Benutzerrechteverwaltung, die sichere Softwareverteilung, die offene Gemeinschaft und die geringere Verbreitung von Linux einen besseren Schutz vor Viren und Malware im Vergleich zu Windows:

• Windows: Häufig im Visier von Viren und Malware, daher ist ein gutes Antivirus-Programm ein Muss.
• Linux: Generell als sicherer betrachtet, vor allem wegen seiner weniger verbreiteten Nutzung und der Art, wie Benutzerberechtigungen gehandhabt werden. Viren sind seltener, aber ein bewusstes Surfen im Internet ist trotzdem wichtig.

In diesem Beitrag erfahrt ihr ausserdem mehr über Antivirus Systeme auf Linux und Co:

Wie steigere ich meine Privatsphäre und Sicherheit

Ein großer Schritt in Richtung Privatsphäre ist bereits getan, wenn man von Windows auf Linux umsteigt. Mit dem Wechsel zu Linux befreit man sich von der "Windows-Wanze" und hat damit einen wichtigen Beitrag zum Schutz der eigenen Privatsphäre geleistet. Die meissten Distros sammeln und übermitteln keine persönlichen Daten an zentrale Server, was bedeutet, dass eure Aktivitäten nicht ständig überwacht und aufgezeichnet werden. So habt ihr die Kontrolle über eure Daten und könnt sicherer und privater arbeiten.

Sicherheit und Privatsphäre sind zwei der Hauptgründe, warum viele Nutzer sich für den Umstieg auf Linux entscheiden. Linux-Systeme sind von Grund auf dafür bekannt, robuste Sicherheitsfeatures zu bieten. Hier sind ein paar Tipps, wie ihr die Sicherheit und Privatsphäre auf eurem Linux-System noch weiter verbessern könnt:

Nutzt die eingebaute Sicherheit von Linux

Linux bietet bereits eine starke Grundlage für Sicherheit:

• Benutzerrechte und Zugriffskontrolle: Linux verwendet ein striktes Berechtigungssystem. Programme haben nur die Rechte, die sie benötigen, und Benutzer können gefährliche Aktionen (wie das Ändern des Betriebssystems) nicht ohne Administratorrechte (root) durchführen.
• SELinux/AppArmor: Viele Distributionen verwenden Sicherheitserweiterungen wie SELinux (Security-Enhanced Linux) oder AppArmor, die eine zusätzliche Schutzschicht bieten, indem sie Anwendungen nur erlauben, auf bestimmte Ressourcen zuzugreifen. SELinux/AppArmor ist quasi ein eingebautes Antivirusprogramm.

DNS-Server ändern

Der DNS-Server, den ihr verwendett, kann einen großen Einfluss auf eure Privatsphäre haben. Einige DNS-Provider wie zum Beispiel der Service Internetprovider, oder auch die Google DNS Server protokollieren eure Anfragen oder filtern Inhalte. Deshalb ist es sinnvoll den Standard-DNS Servers zu ändern.

• Privatsphäre-fokussierte DNS-Server: Ihr könnt zu DNS-Servern wechseln, die bekannt dafür sind, die Privatsphäre zu respektieren, wie zum Beispiel die Server von Mulvad oder digitale-gesellschaft.ch. Diese Anbieter sammeln keine Nutzerdaten und verkaufen diese weiter oder speichern die Anfrage auf ihren Servern. Wir beitreiben auch unseren eigenen DNS Server
• DNS over TLS: Viele moderne Systeme und Browser erlauben es euch, eure DNS-Anfragen über HTTPS oder TLS zu senden, was verhindert, dass Dritte eure Anfragen mitlesen können.

Wir ihr euren DNS Server auf eurem Linux Systemem, oder anderen Geräte ändert, erfahrt ihr hier in diesem Beitrag:

Verwendung von Open-Source-Software

Eine der großen Stärken von Linux ist die Verfügbarkeit von Open-Source-Software, die oft transparenter und vertrauenswürdiger ist, da der Quellcode öffentlich einsehbar ist:

• Transparenz: Open-Source-Programme ermöglichen es euch und unabhängigen Experten, den Code auf Sicherheitslücken oder Hintertüren zu überprüfen.
• Empfohlene Anwendungen: Nutze Open-Source-Anwendungen, die für ihre Sicherheit bekannt sind, wie Thunderbird für E-Mails, LibreOffice für Büroarbeiten und Firefox oder Chromium für das Surfen im Internet. Einen Beitag dazu haben wir euch weiter oben bereits verlinkt.

Weitere Privacy Tipps

Weitere Privacy Tipps findet ihr speziell hier in der Kategorie Privacy Tipps.

Unsere Server für mehr Privatsphäre

Für verschiedene Dienste betreiben wir unsere eigenen Server und Dienstleistungen. Schaut dafür gerne hier vorbei. Die Nutzung ist gratis:

Die Basics der Komandozeile lernen? Sinnvoll aber nicht unbedingt nötig

Heutzutage ist es nicht mehr zwingend notwendig, die Befehlszeile (auch bekannt als Terminal oder Konsole) zu beherrschen, um Linux effektiv zu nutzen. Dies ist eine erhebliche Veränderung im Vergleich zu früheren Zeiten, als die Befehlszeile oft unerlässlich war, um das Betriebssystem zu bedienen und verschiedene Aufgaben zu erledigen.

Moderne Linux-Distributionen wie Ubuntu, Fedora und Mint bieten benutzerfreundliche grafische Benutzeroberflächen (GUIs), die denen von Windows oder macOS ähneln. Diese Oberflächen ermöglichen es Benutzern, die meisten alltäglichen Aufgaben – wie das Verwalten von Dateien, das Installieren und Ausführen von Software, das Konfigurieren von Einstellungen und das Zugreifen auf das Internet – ohne die Notwendigkeit, Kommandozeilenbefehle zu kennen oder zu verwenden, durchzuführen.

Zusätzlich haben Entwicklungen in den Software-Repositories und Paketmanagern es einfacher gemacht, neue Programme zu installieren und Systemaktualisierungen durchzuführen, oft über einfache, grafisch gestützte Tools. Selbst komplexere Systemwartungsarbeiten, die traditionell eine Herausforderung ohne Befehlszeilenkenntnisse darstellten, können heute über spezialisierte GUI-basierte Anwendungen verwaltet werden.

Trotzdem kann ein Grundverständnis der Befehlszeile in bestimmten Situationen von Vorteil sein, wie zum Beispiel bei der Fehlerbehebung, der Automatisierung von Aufgaben durch Skripte oder beim Zugriff auf Server und entfernte Systeme. Aber für alltägliche Benutzer und Standardnutzungsszenarien ist das Erlernen der Befehlszeile für Linux nicht mehr eine unumgängliche Anforderung. Falls ihr aber trotzdem vorhabt, die Basics der Befehlszeile kennen zu lernen, für den haben wir hier einen einfachen Artikel geschrieben:

Geduld und Motiation

Beim Umstieg von Windows und Linux benötigt es vor allem etwas, Motivation! Mit Window umzugehen habt ihr auch nicht in einem Monat erlernt Windows verwenden wir seid Jahrzenten und sind uns mehr oder weniger gewöhnt, wo etwas zu finden ist, beziehungsweise wie die Dinge so funktionieren. Es ist also völlig normal, dass man beim Umstieg nicht immer gleich alles findet, oder gleich alles klappt. Habt also Geduld mit euch selbst. Der Wechsel von Windows zu Linux ist wie der Umzug in ein neues Land mit einer anderen Sprache und Kultur. Es braucht seine Zeit, sich zurechtzufinden, aber sobald ihr drin seid, könnte es euch sogar besser gefallen als vorher!

Das Eintauchen in die Welt von Linux kann eine aufregende Reise sein, insbesondere für diejenigen, die sich nach einer frischen Perspektive auf ihre Computererfahrung sehnen. Linux bietet nicht nur eine Alternative zu den etablierten Betriebssystemen von Großkonzernen wie Microsoft, sondern eröffnet auch die Möglichkeit, ein tieferes Verständnis und eine größere Kontrolle über die eigene digitale Umgebung zu erlangen.

Ein Wechsel zu Linux kann bedeuten, Teil einer lebendigen und engagierten Gemeinschaft zu werden, die auf Offenheit, Zusammenarbeit und die gemeinsame Verbesserung ihrer Software setzt. Im Gegensatz zu proprietären Systemen, die oft geschlossen und restriktiv sind, ist Linux ein Beispiel für die Kraft offener Quellen (Open Source). Jeder Nutzer kann nicht nur Einblick in den Code erhalten, sondern auch Änderungen vorschlagen oder eigene Versionen entwickeln. Dies fördert nicht nur Transparenz und Sicherheit, sondern stärkt auch das Gefühl der Unabhängigkeit von den wirtschaftlichen Interessen großer Softwarehersteller.

Darüber hinaus kann die Auseinandersetzung mit Linux eine Bereicherung für die persönliche und berufliche Entwicklung sein. Das Erlernen der Nutzung von Linux und seiner vielfältigen Tools kann wertvolle technische Fähigkeiten schärfen, die in vielen IT-Bereichen gefragt sind. Für Technikbegeisterte bietet Linux eine Spielwiese für Experimente – von der Softwareentwicklung bis zur Netzwerksicherheit.

In einer Zeit, in der Bedenken bezüglich Datenschutz und -sicherheit zunehmen, bietet Linux eine attraktive Alternative, die mehr Kontrolle und geringere Abhängigkeit von den Datensammlungspraktiken großer Unternehmen verspricht. So wird nicht nur die technische Kompetenz gefördert, sondern auch ein wichtiger Beitrag zur digitalen Selbstbestimmung geleistet. Das Entdecken von Linux ist somit nicht nur das Erlernen eines neuen Betriebssystems – es ist ein Schritt hin zu größerer Unabhängigkeit und einem bewussteren Umgang mit Technologie.

Häufige Fragen zum Umstieg von Windows auf Linux

Was passiert mit meinem Windows-10-PC nach dem Support-Ende?

Der PC läuft weiter, bekommt aber seit dem 14. Oktober 2025 keine kostenlosen Sicherheitsupdates mehr. Über das ESU-Programm lassen sich diese noch bis längstens 13. Oktober 2026 verlängern. Wer das Gerät nicht ausmustern oder auf Windows 11 zwangsupgraden möchte, fährt mit einem Umstieg auf Linux am nachhaltigsten – gerade ältere Hardware läuft damit oft sogar flotter als zuvor.

Welche Linux-Distribution ist Windows am ähnlichsten?

Als Klassiker für Umsteiger gilt Linux Mint mit der Cinnamon-Oberfläche: Startmenü, Taskleiste und Systray fühlen sich sofort vertraut an. Auch Zorin OS ist sehr Windows-nah. Welche Distribution am besten zu euren Bedürfnissen passt, zeigen euch unser Vergleich Welches Linux-Betriebssystem? sowie der interaktive Linux-Finder.

Ist Linux schwierig für Anfänger?

Nein. Moderne Distributionen lassen sich vollständig über eine grafische Oberfläche bedienen – Programme installiert ihr bequem über einen App-Store, ganz ohne Kommandozeile. Der Umstieg fühlt sich für die meisten ähnlich an wie der Wechsel von einer Windows-Version zur nächsten.

Läuft meine Windows-Software unter Linux?

Für die allermeisten Windows-Programme gibt es hervorragende Linux-Alternativen (siehe den Abschnitt «Softwarealternativen» weiter oben). Spezielle Anwendungen, die es nur für Windows gibt, lassen sich häufig über WINE oder in einer virtuellen Maschine weiterbetreiben.

Was kostet Linux?

Nichts. Praktisch alle gängigen Distributionen sind komplett kostenlos – inklusive aller Updates und des grössten Teils der verfügbaren Software. Anders als bei Windows fallen weder Lizenz- noch ESU-Gebühren an.

The post Umstieg von Windows auf Linux: Ein Leitfaden für Anfänger appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was ist chroot

Der Begriff „chroot“ steht für „change root“ und ist eine Operation, die den sichtbaren Root-Verzeichnisbaum für den aktuellen Prozess und seine Childs ändert. Mit chroot könnt ihr den Root-Verzeichnispfad eines Prozesses auf ein Unterverzeichnis eurer Wahl setzen. Das bedeutet, dass der Prozess und alle seine Kindprozesse Dateien und Pfade relativ zu diesem neuen Wurzelverzeichnis (root directory) sehen und nicht zu dem des eigentlichen Hostsystems.

Die Hauptanwendung von chroot ist die Isolation: Prozesse innerhalb einer chroot-Umgebung können nicht auf Dateien außerhalb dieses Verzeichnisbaums zugreifen. Das macht chroot zu einem nützlichen Werkzeug für sicheres Testen, Entwicklung, und zur Systemwiederherstellung, indem man zum Beispiel sicherstellt, dass die Prozesse nur auf bestimmte Teile des Systems Zugriff haben.

Was ist ein Linux Live-System

Ein Linux Live-System ist ein komplettes Betriebssystem, das von einem bootfähigen Medium wie einem USB-Stick oder einer DVD ausgeführt wird, ohne dass es auf der Festplatte des Computers installiert werden muss. Diese Systeme laden das gesamte Betriebssystem in den RAM des Computers, was bedeutet, dass nach dem Neustart keine Spuren auf dem verwendeten Computer hinterlassen werden.

Linux Live-Systeme werden häufig für Systemreparaturen, Software-Demonstrationen, Systemwiederherstellung oder sicheres Surfen verwendet. Da sie das lokale System nicht verändern, sind sie auch eine gute Wahl für das Testen neuer Linux-Distributionen, ohne das bestehende Betriebssystem zu beeinträchtigen.

Benötigte Werkzeuge

• Einen USB Stick
• Eine Linux Distro wie Linux Mint oder Ubuntu
• Balena Etcher

Live Stick erstellen

Zunächst benötigt ihr einen bootfähigen USB-Stick mit einer Linux-Distribution. Beliebte Optionen sind Ubuntu, oder Linux Mint. Ihr könnt das ISO-Image von der offiziellen Website der Distribution herunterladen und mithilfe eines Tools wie Balena Etcher den Stick bootfähig machen. Auf einem Windows System könnt ihr euch einen bootfähigen Stick zum Beispiel auch mit rufus erstellen.

Ladet euch zum Beispiel Linux Mint hier herunter, und flasht das Image mit einem Flashwerkzeug eurer Wahl auf den Stick.

Booten vom USB-Stick

Steckt den USB-Stick in den Computer und starte neu. Ihr müsst die Boot-Reihenfolge im BIOS oder UEFI anpassen, damit der Computer von USB Stick bootet. Schaut direkt nach dem Starten eures Rechners nach Hinweisen wie ihr ins BIOS kommt, meisst ist das aber die DEL oder F2 Taste. Hämmert die Taste bis ihr ins BIOS kommt. Viele BIOSe haben auch ein kürzel um die Bootreihenfolge direkt zu wechseln. Mögliche Tastenkürzel währen F9, F10 oder F12. Seid ihr euch nicht sicher, findet ihr eventuel Information in der Bedienungsanleitung eures Rechners, oder ihr findet heraus welches Mainboard installiert ist, den dann könnt ihr beim Hersteller suchen, welche dann meisstens immer die selben Tastenkürzel verwenden.

Im Tab Boot im Bios könnt ihr die Bootreihenfolge einstellen. Wählt den USB Stick als erstes Bootlaufwerk aus.

Passwort zurücksetzen

Systempartition identifizieren

Sobald ihr im Live-System seid, öffnt das Terminal. Ihr müsst herausfinden, welche Partition eure Linux-Installation enthält. Das könnt ihr mit folgendem Befehl tun:

sudo fdisk -l

Suche in den aufgelisteten Partitionen nach derjenigen mit dem Linux-Dateisystem:

Partition einbinden

Jetzt müsst ihr die richtige Partition einbinden. Zuerst erstellen wir uns einen Ordner indem wir das Linux System mounten. Dass geht mit

sudo mkdir /mnt/linux

Ersetzt die Partition nach /dev/ mit der Partition, die eure Linux-Installation enthält, zum Beispiel in meinem screenshot nvme0n1p3

sudo mount /dev/nvme0n1p3 /mnt

Chroot-Umgebung vorbereiten

Um die Chroot-Umgebung korrekt zu verwenden, müsst ihr einige Systemordner einbinden, damit das System ordnungsgemäß funktioniert:

sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys

chroot-Umgebung betreten

Mit dem folgenden Befehl wechselt ihr in die chroot-Umgebung eurer Linux-Installation auf der Festplatte:bash

sudo chroot /mnt

Passwort zurücksetzen

Mit dem Befehl sudo passwd <benutzername> könnt ihr das Passwort für den jeweiligen Account zurücksetzen. Wechselt das Passwort für euren Benutzer mit beispielsweise mit:

sudo passwd mario

und

sudo passwd root

falls ihr auch das root Passwort vergessen habt.

chroot-Umgebung verlassen und aufräumen

Gebt exit ein, um die chroot-Umgebung zu verlassen. Unmountet die gebundenen Verzeichnisse und die Festplatten:

sudo umount /mnt/sys
sudo umount /mnt/proc
sudo umount /mnt/dev
sudo umount /mnt

System neu starten

Anschliessend könnt ihr das Live System herunterfahren und den USB Stick entfernen. Vergesst nicht, die Bootreihenfolge im BIOS wieder zu zu korrigieren und euer Linux Systemlaufwerk an die erste Stelle zu rücken. Versucht euch anschliessend, mit euren neu erstellem Passwort anzumelden. Habt ihr alles richtig gemacht, seid ihr nun wieder in eurem Linux System

Fazit

Dieses Verfahren ist besonders nützlich, da es euch vollständigen Zugriff auf das Dateisystem und alle Konfigurationsmöglichkeiten bietet, genau so, als würdet ihr direkt auf dem System arbeiten. Es ist eine sehr mächtige Methode, daher solltest du sorgfältig damit umgehen, um keine unbeabsichtigten Änderungen am System vorzunehmen.

The post Linux Passwort zurück setzen mit chroot appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Welche KDE-Plasma-Version ist aktuell? (Stand 2026)

Seit 2024 ist KDE Plasma 6 die aktuelle Generation und löst das langjährige Plasma 5 ab. Plasma 6 setzt standardmässig auf Wayland (statt X11), läuft runder auf moderner Hardware und unterstützt unter anderem HDR und bessere Skalierung für hochauflösende Displays. Welche genaue Version ihr bekommt, hängt von eurer Distribution ab:

• Debian 13 „Trixie" – KDE Plasma 6.3 (Debian bleibt traditionell auf einer geprüften, stabilen Version)
• Ubuntu / Kubuntu 26.04 LTS – KDE Plasma 6.6 (neuere Features, Wayland als Standard)
• Ältere Releases (z. B. Debian 12 „Bookworm", Ubuntu 24.04 LTS) liefern noch Plasma 5.27 – auch das funktioniert mit der Anleitung unten problemlos.

Die gute Nachricht: Die folgenden Installationsbefehle sind versionsunabhängig – ihr bekommt automatisch die Plasma-Version, die für eure Distribution vorgesehen ist. Gerade für Umsteiger von Windows ist KDE wegen seines vertrauten Aufbaus eine ausgezeichnete Wahl; wer noch ganz am Anfang steht, findet im Beitrag Umstieg von Windows auf Linux und im Vergleich Welches Linux-Betriebssystem? die passende Orientierung.

Einleitung

KDE Plasma sticht in der Welt der Linux-Desktop-Umgebungen durch sein modernes Design, seine Anpassbarkeit und seine leistungsstarke Funktionalität hervor. Es ist eine überzeugende Wahl für diejenigen, die eine effiziente und ästhetisch ansprechende Schnittstelle suchen. Die Anordnung der Taskleiste, das Hauptmenu und die Icons in der Taskbar ähneln vom Aufbau stark Windows 10/11.

Hier sind einige der Schlüsselmerkmale, die zu seiner Beliebtheit beitragen:

• Anpassbarkeit: Ihr könnt jeden Aspekt eures Desktops an euren persönlichen Geschmack und eure Workflow-Bedürfnisse anpassen.
• Effizienz: Optimale Leistung auch auf weniger leistungsstarker Hardware sorgt für ein reibungsloses Benutzererlebnis.
• Innovatives Design: Eine elegante und moderne Schnittstelle mit einem intuitiven Layout verbessert die Benutzerfreundlichkeit.
• Integration: Nahtlose Integration mit einer breiten Palette von Anwendungen und Diensten.
• Zugänglichkeit: Funktionen, die auf die Bedürfnisse verschiedener Benutzer eingehen, einschließlich derjenigen mit Behinderungen.
• Reiches Ökosystem: Zugang zu einer Fülle von Anwendungen, die speziell für die KDE-Umgebung entwickelt wurden.

Mit diesen wichtigen Merkmalen und Vorteilen von KDE Plasma im Vordergrund, gehen wir nun zum Hauptinhalt über, die Installation dieser dynamischen Desktop-Umgebung auf eurem Linux Mint oder Ubuntu System.

KDE Plasma Installation

Vorbereitungen

Im ersten Schritt müssen wir die erforderlichen Repositories importieren, um die neueste Version von KDE Plasma und dessen Anwendungen zu installieren. Wenn ihr diesen Schritten folgt, stellt ihr sicher, dass ihr Zugang zur aktuellsten Software für eure KDE-Desktop-Umgebung habt.

Bevor wir mit dem Importieren der notwendigen Repositories beginnen, ist es wichtig, euer System zu aktualisieren, um sicherzustellen, dass wir die neuesten Sicherheitspatches und Software-Updates haben. Um dies zu tun, öffnet das Terminal und führt den folgenden Befehl aus:

sudo apt update && sudo apt upgrade

Führt danach im Terminal den folgenden Befehl aus, um das kubuntu-ppa/backports Repository hinzuzufügen:

sudo add-apt-repository ppa:kubuntu-ppa/backports -y

Optional: Importieren des KDE Backports Extra PPA's

Für eine vollständige KDE-Installation, die zusätzliche Pakete und Extras umfasst, könnt ihr auch das kubuntu-ppa/backports-extra Repository importieren. Führt dazu den folgenden Befehl in eurem Terminal aus:

sudo add-apt-repository ppa:kubuntu-ppa/backports-extra -y

Ähnlich wie der vorherige Befehl fügt dieser das backports-extra Repository zu euren Quellenliste hinzu und bestätigt automatisch die Hinzufügung mit dem -y Flag.

Nachdem ihr die KDE Backports Repositories hinzugefügt habt, müsst ihr den APT-Paketindex aktualisieren, um die neuen Quellen zu berücksichtigen. Führt dazu den folgenden Befehl in eurem Terminal aus:

sudo apt update

Weiter zur Installation von KDE Plasma

Dieser Abschnitt führt ech durch die Installation der KDE Plasma Desktop-Umgebung auf eurem Linux Systems. Drei Installationsmöglichkeiten stehen zur Verfügung, von denen jede eine andere Zusammenstellung von Anwendungen und Funktionen bietet. Abhängig von deinen Vorlieben und Systemanforderungen könnt ihr zwischen einer minimalen, einer Standard- oder einer vollständigen Installation wählen.

Option 1: Installation KDE Standard

Die KDE Standard-Installation umfasst den KDE Plasma Desktop und einen Standard-Satz an Anwendungen. Um diese Option zu installieren, führt den folgenden Befehl in eurem Terminal aus:

sudo apt install kde-standard

Dieser Befehl lädt und installiert den KDE Plasma Desktop zusammen mit einem Standard-Satz an Anwendungen und bietet eine ausgewogene KDE-Erfahrung mit den wesentlichen Tools und Dienstprogrammen.

Option 2: Installation KDE Plasma

Die KDE Plasma-Installation umfasst den KDE Plasma Desktop und einen minimalen Satz an Anwendungen. Diese Option ist geeignet für Nutzer, die eine leichtgewichtige KDE-Erfahrung bevorzugen. Um diese Option zu installieren, führt den folgenden Befehl in eurem Terminal aus:

sudo apt install kde-plasma-desktop

Dieser Befehl installiert den KDE Plasma Desktop und einen minimalen Satz an Anwendungen, was die Nutzung der Systemressourcen niedrig hält, während er dennoch grundlegende KDE-Funktionalitäten bereitstellt.

Option 3: Installation KDE Plasma Full

Die KDE Plasma Full-Installation umfasst den KDE Plasma Desktop und einen umfangreichen Satz an Anwendungen und bietet die umfassendste KDE-Erfahrung. Um diese Option zu installieren, führt den folgenden Befehl in eurem Terminal aus:

sudo apt install kde-full

Dieser Befehl installiert den KDE Plasma Desktop und eine breite Palette von KDE-Anwendungen, was sicherstellt, dass du Zugang zu allen verfügbaren Werkzeugen und Funktionen hast.

Konfigurieren von SDDM für KDE Plasma

Während der Installation könntet ihr auf eine Aufforderung stoßen, die mit „Configuring sddm“ betitelt ist. Es wird empfohlen, KDE Plasma mit dem SDDM-Display-Manager zu betreiben.

Um fortzufahren, drückt die TAB-Taste, um auszuwählen, und drückt dann die Enter.

Um dieses Problem zu vermeiden, führt vor dem Neustart den folgenden Befehl aus, um die Datei /etc/sddm.conf zu aktualisieren:

sudo sed -i '/\[General\]/a InputMethod=' /etc/sddm.conf

Dieser Befehl verwendet sed, um die Zeile InputMethod= unter der Sektion [General] in der sddm.conf-Datei einzufügen. Dadurch wird sichergestellt, dass der Fehler gemildert wird. Diese Anpassung hilft, zu verhindern, dass die virtuelle Tastatur fälschlicherweise als primäres Eingabemittel beim Anmeldebildschirm eingesetzt wird.

Nach den erfolgten Anpassungen, startet euer System neu mit:

sudo systemctl reboot

Anmelden bei der KDE Plasma Desktop-Umgebung

In diesem Abschnitt führen wir euch durch den Prozess der Anmeldung bei der KDE Plasma Desktop-Umgebung auf eurem Linux System. Wenn ihr diesen Schritten folgtt, stellt ihr sicher, dass ihr Zugang zur neu installierten KDE Plasma-Umgebung und ihren Funktionen habt.

Überprüft die KDE Desktop-Umgebung

Nachdem ihr euer System neu gestartet habt, gelangt ihr zum Anmeldebildschirm. Meldet euch nicht sofort an. Bevor ihr euch anmeldet, ist es wichtig, die KDE Plasma Desktop-Umgebung zu überprüfen und auszuwählen.

Sucht den Konfigurationsbutton in der oberen rechten Ecke eures Bildschirms. Ein Klick auf diesen Knopf zeigt die verfügbaren Desktop-Umgebungen an.

In der Liste der Desktop-Umgebungen wählt „Plasma“ anstelle der Standardumgebung „Cinnamon oder Gnome“ oder alternativer Linux Desktop-Umgebungen wie „MATE“ oder „Xfce“. Diese Option sollte sich in einer Leiste in der oberen linken Ecke eures Bildschirms befinden.

Indem ihr Plasma als eure Desktop-Umgebung auswählt, stellt ihr sicher, dass ihr euch bei der Eingabe eurer Anmeldedaten in die KDE Plasma Desktop-Umgebung einloggt.

Nachdem ihr die KDE Plasma Desktop-Umgebung ausgewählt habt, könnt ihr euch nun anmelden. Gebt euren Benutzernamen und euer Passwort ein und klickt dann auf den „Log In“-Knopf oder drückt die EINGABETASTE, um eure KDE Plasma Sitzung zu starten.

Loslegen mit KDE Plasma auf Linux Mint

In diesem Abschnitt geben wir euch Tipps und Anleitungen, um euch den Einstieg in die KDE Plasma Desktop-Umgebung zu erleichtern. Diese Tipps umfassen allgemeine Ratschläge, Anpassungsoptionen und andere nützliche Informationen, um euer KDE Plasma-Erlebnis zu verbessern.

Allgemeine Tips für den KDE Desktop

• Discover: KDE Plasma kommt mit einem integrierten Anwendungsstarter namens "Discover". Diese Anwendung ermöglicht es euch, nach Anwendungen zu suchen, zu durchsuchen und zu installieren sowie euer System zu aktualisieren. Um auf Discover zuzugreifen, klickt auf das Anwendungssymbol in der unteren linken Ecke des Desktops und suche dann in der Suchleiste nach "Discover".
• Systemeinstellungen: Um auf die Systemeinstellungen von KDE Plasma zuzugreifen, klickt mit der rechten Maustaste auf den Desktop und wähle "Arbeitsfläche und Hintergrund einrichten". Von hier aus könnt ihr verschiedene Aspekte euer Desktop-Umgebung anpassen, einschließlich Hintergrundbild, Desktop-Effekte und Bildschirmkanten. Alternativ könnt ihr auf die Systemeinstellungen zugreifen, indem ihr auf das Anwendungssymbol in der unteren linken Ecke klickst und nach "Systemeinstellungen" sucht.
• Dolphin Dateimanager: KDE Plasma enthält einen leistungsstarken und vielseitigen Dateimanager namens Dolphin. Er unterstützt erweiterte Funktionen wie Split-View, Tabs und anpassbare Tastenkombinationen. Um Dolphin zu öffnen, klickt auf das Anwendungssymbol in der unteren linken Ecke und sucht nach "Dolphin".

Anpassungs-Tipps mit KDE Plasma auf Linux Mint

• Desktop-Widgets: KDE Plasma ermöglicht es euch, Widgets auf eurem Desktop hinzuzufügen, um schnellen Zugriff auf verschiedene Tools und Funktionen zu erhalten. Um ein Widget hinzuzufügen, klickt mit der rechten Maustaste auf den Desktop, wählt "Widgets hinzufügen" und zieht dann das gewünschte Widget auf euren Desktop.
• Panel-Anpassung: KDE Plasma verfügt über ein hochgradig anpassbares Panel. Dadurch könnt ihr Widgets hinzufügen, entfernen oder neu anordnen, die Größe und Position des Panels anpassen und sein Erscheinungsbild ändern.
• Globale Themen: KDE Plasma unterstützt globale Themen, die es euch ermöglicht, das Erscheinungsbild eurer Desktop-Umgebung mit nur wenigen Klicks zu ändern. Um ein globales Thema anzuwenden, öffnet die Systemeinstellungen, navigiert zu oder sucht "Globales Design". Durchsucht und wählt ein Thema, das deinem Geschmack entspricht, und klicke auf "Anwenden", um es zu aktivieren. Weitere Designs und Themes können mit dem Button Neue globale Designs holen heruntergeladen werden.

Weitere Tipps zu KDE Plasma

• KRunner: KRunner ist ein leistungsstarkes Such- und Befehlsdienstprogramm in KDE Plasma. Um auf KRunner zuzugreifen, drückt Alt + Leertaste auf eurer Tastatur. Mit KRunner könnt ihr direkt nach Dateien suchen, Anwendungen starten und Befehle ausführen.
• Virtuelle Desktops: KDE Plasma unterstützt virtuelle Desktops, mit denen ihr euren Arbeitsbereich organisieren und zwischen mehreren Desktops wechseln könnt. Um virtuelle Desktops zu konfigurieren, öffnet die Systemeinstellungen, navigiere zu "virtuelle Arbeitsflächen" und wählt dann "hinzufügen" aus. Von hier aus könnt ihr virtuelle Desktops hinzufügen, entfernen oder umbenennen und Tastenkombinationen für das Umschalten zwischen ihnen festlegen.
• Fensterverwaltung: KDE Plasma bietet verschiedene Fensterverwaltungsoptionen wie Kacheln, Einrasten und Gruppieren. Um auf diese Optionen zuzugreifen, klickt mit der rechten Maustaste auf die Titelleiste eines Fensters oder drücke Alt + F3 auf eurer Tastatur. Zusätzlich könnt ihr ein Fenster an den Bildschirmrand ziehen, um es automatisch zu Einrasten oder zu Kacheln.

KDE Desktop Zusätzliche Befehle

Dieser Abschnitt behandelt zusätzliche Befehle und Tipps zur Verwaltung der KDE Plasma Desktop-Umgebung eures Linux Systems. Dazu gehören das Wechseln des Standard-Display-Managers und das Entfernen der KDE Plasma-Umgebung.

Zurück zum default Displaymanager wechseln

Wenn ihr zu einem anderen Display-Manager zurückwechseln möchtet, wie zum Beispiel LightDM für Cinnamon oder GDM für GNOME, könnt ihr dies einfach tun, indem ihr euren Standard-Display-Manager neu konfiguriert.

Öffnet euer Terminal und gebt den folgenden Befehl ein:

sudo dpkg-reconfigure sddm

Wechselt zurück zu LightDM.

Nach dem Wechsel des Display-Managers solltet ihr sicherstellen, dass ihr euer System neu startet, indem ihr folgenden Befehl eingebt:

sudo systemctl reboot

KDE Plasma entfernen

Wenn ihr die KDE Plasma Desktop-Umgebung von eurem Linux System entfernen möchtet, könnt ihr dies mit den folgender Anleitung tun.

Öffnet euer Terminal und gebt den folgenden Befehl ein:

sudo apt autoremove --purge '^kde*' '^kubuntu*' '^plasma*'

Dieser Befehl versucht, alle KDE Plasma-, Kubuntu- und Plasma-bezogenen Pakete von eurem System zu entfernen.

Stellt außerdem sicher, dass die importierten PPAs mit den folgenden Befehlen entfernt werden:

sudo add-apt-repository --remove ppa:kubuntu-ppa/backports -y
sudo add-apt-repository --remove ppa:kubuntu-ppa/backports-extra -y

Nachdem ihr die KDE Plasma Desktop-Umgebung entfernt habt, startet euer System neu, um sicherzustellen, dass die Änderungen wirksam werden:

sudo systemctl reboot

Das Entfernen der KDE Plasma Desktop-Umgebung kann sich auf andere installierte Anwendungen oder Abhängigkeiten auswirken. Geht vorsichtig vor und stellt sicher, dass ihr eine Sicherung eurer wichtigen Daten habt, bevor ihr KDE Plasma von deinem System entfernst. Dies geht zum Beispiel mit Timeshift.

Häufige Fragen zur KDE-Plasma-Installation

kde-plasma-desktop, kde-standard oder kde-full – welches Paket?

kde-plasma-desktop ist die schlanke Basis (nur der Desktop, wenig Zusatzsoftware) – ideal, wenn ihr selbst entscheiden wollt, was dazukommt. kde-standard ergänzt eine sinnvolle Auswahl an KDE-Standardprogrammen und ist für die meisten der beste Kompromiss. kde-full installiert das komplette KDE-Paketuniversum – umfangreich, aber auch deutlich grösser. Im Zweifel fahrt ihr mit kde-standard am besten.

Hat Linux Mint eine eigene KDE-Edition?

Nein. Linux Mint hat seine offizielle KDE-Edition bereits 2017 (mit Mint 18.3) eingestellt und setzt heute auf Cinnamon, MATE und Xfce. KDE Plasma lässt sich aber – genau wie in dieser Anleitung gezeigt – problemlos nachträglich über das Terminal installieren und parallel zum vorhandenen Cinnamon-Desktop nutzen.

Kann ich KDE parallel zu GNOME oder Cinnamon betreiben?

Ja. Mehrere Desktop-Umgebungen können problemlos nebeneinander installiert sein. Welche ihr nutzen möchtet, wählt ihr einfach vor dem Login am Anmeldebildschirm (Display-Manager) aus – euer bestehender Desktop bleibt dabei unangetastet.

Wayland oder X11 – was soll ich wählen?

Unter Plasma 6 ist Wayland der Standard und für die allermeisten die richtige Wahl (moderner, sicherer, besser für hohe Auflösungen). Solltet ihr spezielle Software oder ältere Grafiktreiber haben, die zickt, könnt ihr am Anmeldebildschirm jederzeit testweise auf die X11-Sitzung wechseln.

Fazit

Zusammenfassend bietet die Installation der KDE Plasma Desktop-Umgebung auf Linux Mint eine Vielzahl von Vorteilen und Möglichkeiten zur Anpassung und Optimierung eures Arbeitsbereichs. Mit seiner modernen Benutzeroberfläche, der Benutzerfreundlichkeit und der umfangreichen Funktionalität ist KDE Plasma eine attraktive Option für Nutzer, die nach einer flexiblen und leistungsstarken Desktop-Umgebung suchen.

Durch die Installation von KDE Plasma erhaltet ihr Zugang zu einer Vielzahl von Anwendungen, Tools und Funktionen, darunter der Discover-Anwendungslauncher, die Systemeinstellungen für umfangreiche Anpassungen, den Dolphin-Dateimanager und viele weitere. Die Integration von virtuellen Desktops, Desktop-Widgets, KRunner und globalen Themen ermöglicht es euch, euren Arbeitsbereich nach euren persönlichen Vorlieben und Anforderungen anzupassen und zu optimieren.

Weitere Informationen zu KDE Plasma findet ihr unter https://kde.org/de/plasma-desktop/
Dort findet Ihr auch weitere Bilder und Informationen zu weiteren verfügbaren KDE Apps wie zum Beispiel KDE Connect.

The post KDE Plasma auf Debian, Ubuntu oder Linux Mint installieren appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.