Pocket ID: Passwortloses SSO für deine selbst gehosteten Apps

Erst läuft nur die Fotoverwaltung. Dann kommen ein Wiki, eine Dokumentenablage und ein paar interne Werkzeuge dazu. Irgendwann bedeutet eine Einladung drei neue Konten. Und wenn jemand keinen Zugriff mehr braucht, musst du dich erinnern, in welchen Anwendungen du ihn überall freigeschaltet hast.

Pocket ID zieht die Anmeldung an einer Stelle zusammen. Du betreibst den Dienst selbst und meldest dich mit einem Passkey an. Angebundene Anwendungen vertrauen Pocket ID über OpenID Connect (OIDC). Für ein Homelab oder ein kleines Team ist das ein überschaubarer Einstieg in Single Sign-on (SSO). Pocket ID im Überblick

Was den Login mit Passkeys sicherer macht

SSO und passwortloser Login lösen zwei verschiedene Probleme. SSO sorgt dafür, dass mehrere Apps dieselbe Anmeldung nutzen können. Bei Pocket ID meldest du dich im Alltag mit einem Passkey an. Je nach Gerät bestätigst du das etwa per Fingerabdruck, Gesichtserkennung oder Geräte-PIN.

Technisch signiert dein Passkey eine Anfrage. Pocket ID prüft die Signatur mit dem hinterlegten öffentlichen Schlüssel. Die Anmeldung ist an die passende Domain gebunden. Eine nachgebaute Loginseite auf einer fremden Domain kann deinen Passkey deshalb nicht für den echten Dienst einsetzen. Und beim regulären Login gibt es kein Passwort, das jemand abgreifen oder bei anderen Diensten ausprobieren könnte. FIDO Alliance zur Phishing-Resistenz von Passkeys

Wie gut das schützt, hängt auch von den anderen Anmeldewegen ab. Bleiben lokale App-Passwörter aktiv, gelten deren Risiken weiter. Aktivierst du bei Pocket ID Login-Codes auf Anfrage per E-Mail, wird auch das Postfach zum Zugang. Ein gestohlenes Sitzungscookie kann außerdem eine bereits erfolgte Anmeldung ausnutzen. Anmeldemethoden in Pocket ID

Ein Smartphone bestätigt eine Passkey-Anmeldung für drei angebundene Anwendungen.
Der Passkey bestätigt deine Identität bei Pocket ID. Die angebundenen Apps nutzen diese Anmeldung.

Ein Konto für mehrere Apps, mit getrennten Berechtigungen

Wenn du von der Fotoverwaltung ins Wiki wechselst, kann Pocket ID die bestehende Anmeldung wiederverwenden. Die Apps legen trotzdem eigene Sitzungen an. Beim ersten Besuch kann Pocket ID nachfragen, ob du deine Profildaten mit der App teilen möchtest.

In Pocket ID kannst du pro Anwendung festlegen, welche Gruppen sich anmelden dürfen. So kann die Familie auf die Fotos zugreifen, während ein internes Dashboard nur für eine Admin-Gruppe offensteht. Was jemand innerhalb der App tun darf, entscheidet weiterhin die App. Beim Entzug von Zugriffen lohnt sich ein Blick auf bestehende Sitzungen und lokale Konten, weil sie je nach App bestehen bleiben können. OIDC-Clients und Gruppenzugriff einrichten

Docker Compose, HTTPS und der erste Login

Pocket ID ist unter der BSD-2-Clause-Lizenz verfügbar. Für die Software fällt keine Lizenzgebühr an. Hosting, Updates und Backups gehören weiterhin zum Betrieb. Im Standard-Setup brauchst du mit Docker Compose einen Container und ein dauerhaft eingebundenes Datenverzeichnis. SQLite ist bereits dabei. Quellcode und Lizenz

1. Compose-Datei und .env anlegen

Vorausgesetzt sind Docker mit Compose, eine eigene Subdomain und ein HTTPS-Reverse-Proxy auf demselben Host. Lege ein Verzeichnis für Pocket ID an und speichere dort diese compose.yaml. Die Datenbank und Uploads bleiben in ./data erhalten, wenn der Container ersetzt wird.

services:
  pocket-id:
    image: ghcr.io/pocket-id/pocket-id:v2
    restart: unless-stopped
    env_file: .env
    ports:
      - "127.0.0.1:1411:1411"
    volumes:
      - ./data:/app/data

Lege daneben die Datei .env an. Ersetze die Beispieladresse durch deine eigene HTTPS-Adresse und den Platzhalter durch die Ausgabe von openssl rand -base64 32. Halte die .env privat und sichere den Schlüssel für die Wiederherstellung.

APP_URL=https://id.example.com
ENCRYPTION_KEY=HIER_DEINEN_ZUFALLSSCHLUESSEL_EINTRAGEN

2. HTTPS einrichten

Lass deine Subdomain auf den Reverse Proxy zeigen und leite sie mit gültigem TLS-Zertifikat an http://127.0.0.1:1411 weiter. Der Port ist in diesem Beispiel nur auf dem Docker-Host erreichbar. Für Caddy, der direkt auf dem Host läuft, sieht der Eintrag so aus. Verwende dieselbe Domain wie in APP_URL.

id.example.com {
    reverse_proxy 127.0.0.1:1411
}

Läuft dein Proxy selbst als Container, verbinde ihn mit Pocket ID über ein gemeinsames Docker-Netz und verwende dort pocket-id:1411 als Ziel. In diesem Fall kannst du den Abschnitt ports weglassen. Pocket-ID-Dokumentation zu Reverse Proxys

3. Starten und den ersten Admin einrichten

Führe im Verzeichnis mit der Compose-Datei diese Befehle aus.

docker compose up -d
docker compose ps

Öffne https://id.example.com/setup mit deiner eigenen Domain. Lege das erste Admin-Konto an, registriere einen Passkey und teste die Anmeldung in einem privaten Browserfenster. Halte den Zugriff auf die Setup-Seite bis zur Einrichtung auf deinen Admin-Zugang beschränkt. Sobald das erste Konto existiert, ist die Setup-Seite geschlossen. Wenn der Container nicht läuft, helfen die Meldungen aus docker compose logs --tail=50 pocket-id. Offizielle Installationsanleitung

Neue Nutzer anlegen und bestehende Konten verbinden

Wenn du ein neues Projekt aufsetzt, kannst du OIDC von Anfang an einplanen. Benutzerkonten in Pocket ID legst du zum Beispiel selbst an oder du verschickst einen Einladungslink. Die Nutzer hinterlegen ihren eigenen Passkey. Für jede App richtest du einen OIDC-Client ein, hinterlegst ihre genaue Rücksprungadresse und gibst der Anwendung die Discovery-URL, die Client-ID und bei einem vertraulichen Client das Client-Secret. Benutzerverwaltung in Pocket ID · Erste App verbinden

Immich zeigt, was das praktisch bringt. Mit Auto Register legt Immich beim ersten erfolgreichen SSO-Login selbst ein lokales Konto an. Wer schon ein Immich-Konto mit Fotos hat, kann es in den Kontoeinstellungen mit der OIDC-Identität verbinden und das vorhandene Konto weiterverwenden. Damit sparst du dir bei neuen Projekten die doppelte Kontopflege und kannst bei bestehenden Anwendungen erst mit einem Testkonto prüfen, wie die Verknüpfung funktioniert. Immich-Dokumentation zu OIDC · Immich mit Pocket ID verbinden

Wenn Konten schon vor der ersten Anmeldung bereitstehen oder zentral wieder entzogen werden sollen, kann Pocket ID Benutzer und Gruppen per SCIM an die App übertragen. Dafür braucht die Zielanwendung einen passenden SCIM-Endpunkt. Für viele kleine Projekte reicht die Kontoanlage beim ersten Login. SCIM in Pocket ID

Wenn der zentrale Login ausfällt

Pocket ID kann zum Single Point of Failure werden. Wenn der Container, der Host, DNS oder der HTTPS-Zugang ausfällt, können neue SSO-Anmeldungen an mehreren Diensten gleichzeitig scheitern. Bestehende App-Sitzungen können weiterlaufen, bis sie ablaufen oder die App erneut einen Token vom Login-Dienst braucht.

Ein unterbrochener Weg zu einem Server und drei Symbole für den Notfallplan: Sicherheitsschlüssel, Backup und unabhängiger Zugang.
Ein Ersatz-Passkey, ein getestetes Backup und ein unabhängiger Notzugang helfen in unterschiedlichen Ausfällen.

Der Praxisbericht von uptime.bet empfiehlt einen zweiten Admin-Passkey und ein Backup von Daten und Schlüssel. Für den Betrieb würde ich beides getrennt testen. Der Ersatz-Passkey hilft beim Geräteverlust. Bei einem Serverausfall brauchst du einen Weg, den Dienst wiederherzustellen oder deine wichtigsten Apps direkt zu erreichen. Pocket ID im Selfhosting-Praxisbericht von uptime.bet

  • Ersatz-Passkey hinterlegen. Registriere für Admins einen zweiten, unabhängig verfügbaren Passkey, etwa auf einem separaten Hardware-Sicherheitsschlüssel. Wenn alle Admin-Passkeys weg sind und Pocket ID läuft, kannst du mit unabhängigem Serverzugang per CLI einen zeitlich begrenzten Einmalzugang erzeugen. Kontowiederherstellung in Pocket ID
  • Wiederherstellung testen. Sichere das Datenverzeichnis konsistent, bei SQLite zum Beispiel bei gestopptem Container. Sichere auch die Compose-Konfiguration, den Verschlüsselungsschlüssel und die nötige Proxy-Konfiguration geschützt außerhalb des Hosts. Teste die Wiederherstellung isoliert und plane für den Ernstfall dieselbe Login-Domain ein, damit bestehende Passkeys weiter nutzbar sind.
  • Unabhängigen Notzugang behalten. Wo die Anwendung es unterstützt, halte für kritische Dienste ein separates lokales Admin-Konto mit starkem Passwort und MFA bereit. Sorge dafür, dass du im Ausfall sowohl die App als auch die Zugangsdaten ohne Pocket ID erreichst.
  • Von außen prüfen. Überwache die HTTPS-Adresse von einem System aus, das bei einem Ausfall des Pocket-ID-Hosts weiterläuft. Teste zusätzlich nach Änderungen einen echten Login in einer angebundenen App. Ein erreichbarer Webserver allein sagt wenig über die vollständige Anmeldung aus. Uptime Kuma auf sotzny.de

Pocket ID ist kostenlos. SSO in der Ziel-App kann trotzdem kosten.

In der Selfhosting-Szene hat diese Preisgrenze einen Namen: SSO Tax. Gemeint ist, dass du für die zentrale Anmeldung ein größeres Paket kaufen musst, obwohl du dessen übrige Funktionen kaum nutzt. Das ist gerade bei einer Handvoll Konten schwer zu rechtfertigen. Wie die Übersicht von SSD Nodes zeigt, lohnt sich aber der Blick auf die konkrete Edition. Es gibt genug Gegenbeispiele, um sich bei der App-Auswahl Spielraum zu verschaffen. Einordnung der SSO Tax bei SSD Nodes

Bei Bitwarden ist der SSO-Login für Organisationen beispielsweise Teil von Enterprise. Immich bringt OIDC auch ohne kostenpflichtiges SSO-Paket mit. Wenn du eine App ohnehin nur allein nutzt, kann der vorhandene Login ausreichen. Für neue Projekte mit mehreren Anwendungen lohnt es sich, vorab zu prüfen, ob die geplante Edition einen eigenen OIDC-Anbieter zulässt und ob der Login auch in den genutzten mobilen Apps funktioniert. Bitwarden-Editionen · Übersicht selbst gehosteter Apps mit kostenlosem OIDC

Fazit

Pocket ID ist einfach einzurichten, leichtgewichtig und absolut sinnvoll, wenn mehrere eigene Anwendungen denselben Login nutzen sollen. Gerade bei neuen Projekten lässt sich OIDC von Anfang an einplanen, bevor du überall getrennte Konten aufgebaut hast. Für den Einstieg reicht eine App. Wenn der Login, der zweite Admin-Passkey und der Wiederanlauf funktionieren, kannst du die nächsten Dienste anbinden.

Veröffentlicht unter Blogroll | Verschlagwortet mit , , , , | Kommentar hinterlassen

Thunderbird aufräumen: Infomails nach fünf Tagen verschieben und wichtige Mails markieren

Ich will meine Backup-Meldungen im Posteingang sehen. Wenn alles durchgelaufen ist, brauche ich die Meldung dort aber irgendwann nicht mehr. Bei Newslettern und anderen Benachrichtigungen ist es ähnlich. Ein paar Tage sind sie interessant, danach sammeln sie sich an. Dazwischen liegen dann die Mails, die ich eigentlich im Blick behalten will.

Ich habe mir dafür in Thunderbird zwei Filter eingerichtet. Der eine verschiebt Infomails nach fünf Tagen in den Ordner „Informationen“. Der andere gibt Mails von wichtigen Kontakten beim Eingang einen Stern. Dafür reichen die eingebauten Nachrichtenfilter von Thunderbird.

Infomails nach fünf Tagen verschieben

Die Absender pflege ich in einem eigenen Adressbuch. Wenn ein weiterer Newsletter dazukommt, ergänze ich dort die Adresse und kann den Filter so lassen, wie er ist.

  1. Lege das Adressbuch Info-Absender an und trage die E-Mail-Adressen ein, die Thunderbird einsortieren darf.
  2. Lege im Mailkonto den Ordner Informationen an. Öffne Extras → Filter, wähle das passende Konto und erstelle einen neuen Filter.
  3. Aktiviere die regelmäßige Ausführung alle 10 Minuten. Für den ersten Test aktiviere auch Manuelles Ausführen. Der regelmäßige Lauf findet statt, während Thunderbird geöffnet ist. Mozilla-Support zur regelmäßigen Ausführung
  4. Wähle Alle Bedingungen erfüllen und trage diese fünf Zeilen ein.
FeldPrüfungWert
Vonist in meinem AdressbuchInfo-Absender
Alter in Tagenist größer als5
Statusist nichtBeantwortet
Statusist nichtGekennzeichnet
Statusist nichtWeitergeleitet
  1. Wähle als Aktion Nachricht verschieben in und als Ziel den Ordner Informationen.

Wenn eine Mail älter als fünf Tage ist und alle übrigen Bedingungen erfüllt, verschiebt Thunderbird sie beim nächsten Filterlauf. Habe ich schon geantwortet, die Mail weitergeleitet oder ihr einen Stern gegeben, bleibt sie liegen. Wenn ich sie nur gelesen habe, darf sie weiterhin in den Ordner „Informationen“. Thunderbird-Quellcode zur Statusprüfung

Filterdialog mit Absender-Adressbuch, Fünf-Tage-Grenze, Statusausnahmen und Zielordner.

Wenn ein Backup-System Erfolge und Fehler von derselben Adresse meldet, würde ich zusätzlich den Betreff prüfen. So kann ich gezielt die Erfolgsmeldungen verschieben. Welcher Betreff dazu passt, hängt vom Backup-System ab.

Ein goldener Briefumschlag mit Stern hebt sich zwischen blauen Umschlägen ab.

Wichtige Mails bekommen einen Stern

Für wichtige Kontakte habe ich ein zweites Adressbuch angelegt. So kann ich die Liste nebenbei pflegen, wenn mir im Posteingang jemand auffällt, dessen Mails ich künftig schneller sehen will.

  1. Lege das Adressbuch Wichtige Kontakte an und füge die Absenderadressen hinzu.
  2. Erstelle unter Extras → Filter im passenden Mailkonto einen zweiten Filter und aktiviere Nachrichtenabruf. Für einen Test mit vorhandenen Mails kannst du auch Manuelles Ausführen aktivieren.
  3. Setze die Bedingung Von → ist in meinem Adressbuch → Wichtige Kontakte. Wähle als Aktion Nachricht kennzeichnen. Damit setzt Thunderbird den Stern beim Eingang. Thunderbird-Hilfe zur Kennzeichnung per Filter
Filterdialog mit dem Adressbuch „Wichtige Kontakte“ und der Aktion für den Stern.

Filter manuell testen

Wenn du einen einzelnen Filter testen willst, markiere im Filterfenster zuerst seine Zeile. Wähle unten den Ordner, dessen Nachrichten du prüfen willst, zum Beispiel den Posteingang. Klicke erst dann auf Jetzt ausführen. Das Filterfenster ist nicht modal. Es kann geöffnet bleiben, während du im Thunderbird-Hauptfenster weiterarbeitest. Prüfe deshalb vor dem Klick noch einmal, welche Filterzeile markiert ist. Mozilla-Support zum manuellen Filtertest

Wenn du die Filter gesammelt ausführen willst, wähle den gewünschten Ordner im Hauptfenster und gehe zu Extras → Filter auf Ordner anwenden. Thunderbird führt dann für diesen Ordner alle aktiven Filter des Kontos aus, bei denen Manuelles Ausführen eingeschaltet ist. Thunderbird-Quellcode zur Ordneraktion

Zum Gegencheck kannst du eine zweite Mail desselben Absenders nehmen, die jünger als fünf Tage ist oder einen Stern hat. Die sollte im Posteingang bleiben.

Veröffentlicht unter Nützliches | Verschlagwortet mit , , , , | Kommentar hinterlassen

Uptime Kuma: Ausfälle erkennen, bevor jemand sie meldet

Du öffnest morgens deine Website und bekommst einen 502-Fehler. Seit wann ist sie nicht erreichbar? Und war es nur ein kurzer Aussetzer oder lief die Seite die ganze Nacht nicht? Mit Uptime Kuma kannst du solche Ausfälle automatisch erkennen und im Verlauf nachsehen, seit wann die Prüfungen fehlschlagen.

Was ist Uptime Kuma?

Uptime Kuma ist ein Open-Source-Projekt von Louis Lam, das du auf einem eigenen Server betreibst. Für jeden Dienst legst du einen Monitor an und stellst ein, wie oft Kuma prüfen soll. Im Dashboard siehst du, welche Dienste gerade erreichbar sind, wie sich ihre Antwortzeiten entwickeln und wann Prüfungen fehlgeschlagen sind. Für Benachrichtigungen kannst du unter anderem E-Mail, Telegram, Discord oder Gotify einrichten.

Uptime-Kuma-Dashboard mit Monitorliste und Verlauf der Erreichbarkeit
Das Dashboard zeigt die überwachten Dienste und den Verlauf der Prüfungen. Quelle: Uptime Kuma auf GitHub.

Was sich zu überwachen lohnt

  • Website oder API: Ein HTTPS-Check prüft, ob der Endpunkt wie erwartet antwortet. Mit einem Keyword-Check kannst du zusätzlich nach einem Text suchen, der auf der richtigen Seite vorkommen muss. Das hilft, wenn eine Fehlerseite trotzdem HTTP 200 zurückgibt.
  • Dienst im Heimnetz: Ein TCP-Check prüft, ob sich eine Verbindung zum Port aufbauen lässt. Für eine Datenbank sagt dir das, ob der Port erreichbar ist. Ob eine Anmeldung oder Abfrage funktioniert, prüft der TCP-Check allein nicht.
  • Backup oder Cronjob: Bei einem Push-Monitor meldet sich das Skript selbst. Bleibt die Meldung länger als erwartet aus, kann Kuma Alarm schlagen. So fällt auch ein Job auf, der gar nicht erst gestartet ist.

Push-Monitore für Backups und geplante Jobs

Ein Backup-System sendet ein Signal an den Monitor. Eine Uhr steht für das erwartete Intervall.
Das Backup-Skript meldet seinen Status an Uptime Kuma.

Bei einem HTTPS-Monitor ruft Kuma den Dienst auf. Bei einem Push-Monitor läuft es umgekehrt: Dein Skript ruft die von Kuma erzeugte URL auf und meldet damit, dass der Job gelaufen ist. Die Benachrichtigung an dich stellst du separat ein, zum Beispiel per E-Mail oder Telegram.

Für meine Restic-Backups meldet das Skript den Erfolg an Uptime Kuma. Wichtig ist der Zeitpunkt: Die Erfolgsmeldung gehört ans Ende des Jobs, nachdem Restic erfolgreich beendet wurde. Startet der Job gar nicht oder kommt die Meldung wegen eines Netzwerkproblems nicht an, erkennt Kuma nach Ablauf des erwarteten Intervalls, dass die Rückmeldung fehlt.

Ein Fehler lässt sich auch direkt mit status=down melden. Für die Erfolgsmeldung verwendest du status=up. Bei einem täglichen Job sollte das Intervall in Kuma etwas länger als 24 Stunden sein, wenn die Laufzeit schwankt. Behandle die Push-URL wie ein Passwort. Wer den Token kennt, kann den Status des Monitors melden. Die Parameter stehen in der Projektdokumentation zur Push-Schnittstelle.

Server prüfen: vom Ping bis zur Anwendung

Eine zentrale Überwachung prüft einen Server, eine Datenbank und einen Gameserver.
Je nach Dienst prüft Uptime Kuma die Erreichbarkeit oder fragt das jeweilige Protokoll ab.

Ein Ping zeigt dir, ob der Host aus Sicht von Kuma auf ICMP antwortet. Der Webserver kann dabei längst ausgefallen sein. Ein TCP-Check geht einen Schritt weiter und versucht, eine Verbindung zum Port aufzubauen. Welcher Check passt, hängt davon ab, was ausfallen kann und was du davon mitbekommen willst.

Für Microsoft SQL Server, PostgreSQL, MySQL/MariaDB, MongoDB und Redis gibt es eigene Monitortypen. Wenn dich interessiert, ob Kuma sich tatsächlich mit der Datenbank verbinden kann, ist ein passender Datenbankmonitor aussagekräftiger als ein offener TCP-Port. Ob die Anwendung mit ihrem eigenen Konto auf die benötigten Daten zugreifen kann, prüfst du am besten zusätzlich über einen geeigneten Health-Endpunkt.

Ähnlich ist es bei Docker: Kuma kann über die Docker-Schnittstelle prüfen, ob ein Container läuft. Ob die Webanwendung darin eine brauchbare Antwort liefert, prüfst du separat mit HTTPS oder einer JSON-Abfrage. Wie du den Docker-Monitor einrichtest, steht im Projektwiki.

Für Gameserver gibt es Steam- und GameDig-Monitore. Sie fragen unterstützte Spielserver über ihr Abfrageprotokoll ab. Für andere Dienste gibt es unter anderem DNS-, MQTT- und gRPC-Monitore. So kannst du beispielsweise einen erwarteten DNS-Eintrag oder eine bestimmte Antwort eines gRPC-Dienstes prüfen. Einen Überblick findest du im Projekt-Repository.

Von wo aus wird geprüft?

Für interne Dienste wie ein NAS ist ein Monitor im Heimnetz sinnvoll. Für eine öffentliche Website lohnt sich ein Check von außerhalb. Läuft Kuma auf demselben Host wie die Website, fallen bei einem Host-Ausfall beide gleichzeitig aus. Ähnlich ist es bei einem Internetausfall zu Hause: Ein Kuma im selben Netz kann dann womöglich keine Meldung mehr verschicken. Ein Monitor auf einem unabhängigen Server kann die öffentliche Erreichbarkeit weiterhin prüfen.

Wie schnell du einen Ausfall bemerkst, hängt vom Prüfintervall, den eingestellten Wiederholungen und dem Benachrichtigungskanal ab. Eine kurze Unterbrechung zwischen zwei Prüfungen kann unbemerkt bleiben. Der Verlauf hilft dir, die Fehlersuche zeitlich einzugrenzen. Für die Ursache brauchst du je nach Problem zusätzlich Logs, Metriken oder einen Blick in die Anwendung.

Dashboard und Statusseite

Das Dashboard ist für dich als Betreiber gedacht. Über eine Statusseite kannst du ausgewählte Dienste öffentlich anzeigen. Wer gerade auf deine Website oder API angewiesen ist, kann dort nachsehen, ob eine Störung bekannt ist.

Öffentliche Uptime-Kuma-Statusseite mit Verfügbarkeitsverlauf für mehrere Dienste
Beispiel einer Statusseite mit mehreren Diensten und ihrem Verfügbarkeitsverlauf. Quelle: Uptime Kuma auf GitHub.

Uptime Kuma mit Docker Compose starten

Du brauchst einen Host mit Docker und dem Compose-Plugin. Lege dort einen Ordner für Uptime Kuma an und speichere diese Datei als compose.yaml. Das Beispiel basiert auf der Compose-Datei des Projekts.

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - ./data:/app/data

Starte den Container im Verzeichnis der compose.yaml und prüfe anschließend seinen Status.

docker compose up -d
docker compose ps

Sobald der Container läuft, erreichst du die Ersteinrichtung auf dem Docker-Host unter http://localhost:3001. Die Portbindung an 127.0.0.1 hält die Oberfläche lokal. Wenn Docker auf einem entfernten Server läuft, kannst du für die Einrichtung einen SSH-Tunnel nutzen.

Die Konfiguration und der Verlauf liegen im lokalen Ordner ./data neben der Compose-Datei. So bleiben sie erhalten, wenn du den Container neu erstellst. Nutze dafür ein lokales Dateisystem. NFS wird laut Installationsanleitung nicht unterstützt.

Mit einem Monitor anfangen

Wenn du Kuma erst ausprobieren möchtest, gibt es eine offizielle Live-Demo. Lege zuerst einen HTTPS-Monitor für einen wichtigen Dienst an und verbinde ihn mit deinem Benachrichtigungskanal.

Ob die Meldung wirklich ankommt, kannst du mit einem separaten Testdienst prüfen. Lass Kuma den Dienst zunächst als erreichbar anzeigen, stoppe ihn kurz und warte auf den Alarm. Starte ihn dann wieder und prüfe, ob der Monitor zurück auf „Up“ wechselt. So weißt du vor dem ersten echten Ausfall, dass die Überwachung bis zur Benachrichtigung funktioniert.

Veröffentlicht unter Nützliches | Verschlagwortet mit , , , , , | 1 Kommentar

8 KI-Begriffe einfach erklärt – von MCP bis Superintelligenz

Du bittest eine KI, einen Blogbeitrag vorzubereiten. Sie schreibt den Text, legt einen Entwurf in WordPress an und fügt Bilder ein. Hinter diesem Ablauf stecken gleich mehrere Dinge, die in KI-Diskussionen schnell durcheinandergeraten. Da ist vom Agenten die Rede, von MCP, von Skills und manchmal auch vom Harness. Was davon macht eigentlich was?

Hier sind acht Begriffe, die dir helfen, solche Funktionen einzuordnen. Los geht’s mit dem Teil, der ein Sprachmodell überhaupt erst mit Werkzeugen verbindet.

Weiterlesen →
Veröffentlicht unter Blogroll | Verschlagwortet mit , , , | Kommentar hinterlassen

iCloud Kalender & Kontakte mit Thunderbird synchronisieren

Lange Zeit war die Synchronisation von Apple iCloud mit Thunderbird eine echte Herausforderung. Man brauchte umständliche Brücken-Lösungen oder Drittanbieter-Plugins – und oft genug hat das Ganze dann doch nicht richtig funktioniert.

Das ist heute kein Thema mehr: Thunderbird unterstützt iCloud Kalender und Kontakte nativ. Keine zusätzlichen Plugins, keine Bastelei. Hier die Schritt-für-Schritt-Anleitung.

iCloud-Kalender in Thunderbird einbinden

  1. Öffne Thunderbird und klicke unten links auf das Kalender-Symbol, um in die Kalender-Ansicht zu wechseln.
  2. Klicke mit der rechten Maustaste in die Kalender-Liste links und wähle „Neuen Kalender …” aus.
  3. Es öffnet sich ein Dialog. Wähle „Im Netzwerk” aus und klicke auf „Weiter”.
  4. Als Benutzername trägst du deine Apple-ID (E-Mail-Adresse) ein.
  5. Als Adresse verwendest du:

  6. https://caldav.icloud.com
  7. Thunderbird fragt nun nach einem Passwort – dein normales Apple-ID-Passwort funktioniert hier nicht. Du benötigst ein App-spezifisches Passwort (siehe nächster Abschnitt).
  8. Nach erfolgreicher Eingabe werden dir deine iCloud-Kalender angezeigt. Wähle aus, welche du synchronisieren möchtest.

App-spezifisches Passwort erstellen

Apple erlaubt aus Sicherheitsgründen keine direkte Anmeldung mit deinem Hauptpasswort bei Drittanbieter-Apps. Stattdessen erzeugst du für jede App ein eigenes, einmaliges Passwort:

  1. Rufe https://appleid.apple.com auf und melde dich mit deiner Apple-ID an.
  2. Gehe zum Bereich „App-spezifische Passwörter” (unter „Sicherheit”).
  3. Klicke auf „Passwort erzeugen …” und gib einen Namen ein (z. B. „Thunderbird Kalender”).
  4. Apple generiert ein Passwort im Format xxxx-xxxx-xxxx-xxxx.
  5. Kopiere es sofort und füge es in Thunderbird ein – das Passwort wird nur einmal angezeigt.

⚠️ Wichtig: Jedes App-spezifische Passwort kann nur einmalig verwendet werden. Für Kalender und Kontakte brauchst du jeweils ein separates Passwort.

iCloud-Kontakte synchronisieren

Die Vorgehensweise für die Kontakte ist fast identisch:

  1. Wechsle in Thunderbird zu den Kontakten (Adressbuch-Symbol).
  2. Klicke auf „Neues Adressbuch” → „CardDAV”.
  3. Gib erneut deine Apple-ID (E-Mail) als Benutzername ein.
  4. Als Server-Adresse verwendest du wieder:

  5. https://caldav.icloud.com
  6. Thunderbird fordert ein Passwort an – erstelle ein neues, separates App-spezifisches Passwort (wie oben beschrieben).
  7. Die Synchronisation startet automatisch. Deine iCloud-Kontakte erscheinen nun im Thunderbird-Adressbuch.

Worauf du achten solltest

  • Einmalige Passwörter: Jedes App-spezifische Passwort kann nur für einen Dienst verwendet werden. Kalender und Kontakte brauchen also zwei verschiedene Passwörter.
  • Keine Plugins nötig: Thunderbird bringt CalDAV (Kalender) und CardDAV (Kontakte) ab Werk mit – die alte Extension „Provider für CalDAV & CardDAV” wird seit dem Update automatisch deaktiviert.
  • Zwei-Wege-Synchronisation: Änderungen in Thunderbird werden an iCloud übertragen und umgekehrt. Du kannst also sowohl auf dem Mac/iPhone als auch am PC mit Thunderbird arbeiten.

Fazit

Die native iCloud-Anbindung in Thunderbird funktioniert überraschend sauber. Keine Zusatztools, keine Plugins, keine Wartung – einfach einrichten und loslegen. Wer Thunderbird beruflich oder privat nutzt und gleichzeitig im Apple-Ökosystem unterwegs ist, bekommt hier eine unkomplizierte Brücke zwischen beiden Welten.


📝 *Ausführliche Anleitung mit Video:* ekiwi-blog.de

Veröffentlicht unter Allgemein | 1 Kommentar