Blog

• Wrapper /usr/terruhn.it/sbin/kisp-wp (root:root, 755) startet docker compose -p kisp run --rm -T wpcli wp ….
• Allowlist nach Unterbefehl-Paaren: post create|get|list|update|delete|exists, post meta get|list|add|update|delete, term …, menu …, menu item …, media import, option get.
• Gesperrt: --exec, --require, --ssh, --http, --path, --config, --allow-root, --prompt, --user; Optionen vor dem Unterbefehl; alle nicht gelisteten Unterbefehle (eval, eval-file, shell, db, package, plugin, option update …).
• sudo-Regel /etc/sudoers.d/kisp-wp: rene ALL=(root) NOPASSWD: /usr/terruhn.it/sbin/kisp-wp, geprüft mit visudo -cf.
• Inhalt per STDIN: echo '…' | sudo -n /usr/terruhn.it/sbin/kisp-wp post create - --post_status=draft --porcelain.
• Löschen ohne --force legt in den Papierkorb.

• Benutzer anlegen (root, einmalig):

docker compose -p kisp run --rm wpcli wp user create claude claude@thekeepitsimpleproject.org --role=editor --display_name="Claude (KI)" --nickname="Claude (KI)" --porcelain

• Wrapper 0.2 setzt --user=claude bei jedem Aufruf; --user vom Aufrufer wird abgelehnt.
• Rolle Editor, weil Seiten erst ab dieser Rolle anlegbar sind. Keine Rechte für Plugins, Themes und Benutzer.
• Bestehende Inhalte umgestellt:

sudo -n /usr/terruhn.it/sbin/kisp-wp post update 11 --post_author=3

• Die E-Mail-Adresse ist ein Pflichtfeld. Das Konto dient nicht der Anmeldung im Browser.

• Abgelehnter Aufruf:

sudo -n /usr/terruhn.it/sbin/kisp-wp post update 27 29 --post_status=publish

Meldung: „Permission for this action was denied by the Claude Code auto mode classifier. Reason: [External System Writes]“.

• Im Auto-Modus bewertet ein Klassifikator jeden Befehl. Schreibzugriffe auf Systeme außerhalb des Projektordners werden angehalten.
• Eine Freigabe im Chat hebt das nicht auf. Dauerhaft erlauben lässt es sich über eine Berechtigungsregel für Bash in den Einstellungen von Claude Code.
• Für KISP bleibt es dabei: Veröffentlichen per Browser oder per !-Befehl im Terminal von Claude Code.

• Datei infra/mu-plugins/kisp-glossar-popup.php, installiert unter /data/terruhn.it/kisp/wordpress/wp-content/mu-plugins/:

install -o www-data -g www-data -m 644 /data/terruhn.it/CLAUDE/kisp/infra/mu-plugins/kisp-glossar-popup.php /data/terruhn.it/kisp/wordpress/wp-content/mu-plugins/kisp-glossar-popup.php

• Das Plugin gibt über wp_footer ein <style> und ein <script> inline aus. Es lädt nichts von außen und setzt keine Cookies. Der statische Export enthält beides.
• Das Popup ist ein <dialog>, geöffnet mit showModal(). Escape, Fokusführung und Hintergrund liefert der Browser. Die Farben stammen von den Systemfarben Canvas und CanvasText, deshalb passen Hell und Dunkel.
• Der Handler greift bei Links, deren Pfad auf /glossar/ endet und die einen Anker tragen. Er lässt Strg-, Meta-, Umschalt-, Alt- und Mittelklick durch, ebenso Klicks auf der Glossar-Seite selbst und Klicks auf Links im Popup:

if (a.closest('dialog.kisp-glossar')) { return; }

• Die Glossar-Seite wird einmal mit fetch geladen, mit DOMParser gelesen und zwischengespeichert. Der Eintrag wird über getElementById gefunden und als DOM-Knoten kopiert, nicht als Text in innerHTML. Sprungmarken (span[id]) und die id des Absatzes werden entfernt, damit keine doppelten Anker entstehen.
• Fällt etwas aus (Netzwerk, fehlender Eintrag, ältere Browser ohne <dialog>), wird der normale Link benutzt.
• Test: Beitrag öffnen, Begriff anklicken, Escape drücken, Strg-Klick prüfen, in der Konsole (F12) auf Fehler achten.
• Solange die Glossar-Seite ein Entwurf ist, zeigt das Popup sie nur eingeloggten Nutzern; Besucher fallen auf den Link zurück.

• Befund: wpcli hing nur an kisp_internal (internal: true, ohne Gateway), der Name der Seite ließ sich nicht auflösen:

docker compose -p kisp run --rm wpcli getent ahostsv4 wordpress.thekeepitsimpleproject.org

Ausgabe vorher: leer. Nachher: 172.17.0.1.

• Lösung in infra/compose.yaml (0.2 und höher): beim Dienst wpcli

extra_hosts:
  - "${KISP_HOST}:host-gateway"
networks:
  - kisp_internal
  - default

Das Standardnetz ist nötig, weil host-gateway im internen Netz nicht erreichbar ist.

• Im Dienst wordpress stand extra_hosts bereits. /etc/hosts im Container enthält zwei Einträge für den Namen: 172.17.0.1 und fd00:18:10:2011:ffff::1.
• Test beider Adressfamilien aus dem Container:

docker exec kisp-wp php -r 'foreach ([4,6] as $v) { $c = curl_init("https://thekeepitsimpleproject.org/"); curl_setopt_array($c, [CURLOPT_IPRESOLVE => $v == 4 ? CURL_IPRESOLVE_V4 : CURL_IPRESOLVE_V6, CURLOPT_RETURNTRANSFER => 1, CURLOPT_TIMEOUT => 10]); curl_exec($c); echo "IPv$v: " . curl_getinfo($c, CURLINFO_HTTP_CODE) . " " . curl_error($c) . "\n"; }'

Ergebnis: IPv4 401 (Passwortschutz von Caddy, erwartet), IPv6 sofortiger Verbindungsfehler (Container ohne IPv6-Routing).

• TODO: Herkunft der IPv6-Adresse im /etc/hosts klären.

• Konstante in der wp-config.php setzen. WORDPRESS_CONFIG_EXTRA greift nur beim Erzeugen der Datei, im laufenden Stack hilft:

docker compose -p kisp run --rm wpcli wp config set DISABLE_WP_CRON true --raw
docker compose -p kisp run --rm wpcli wp cron test

wp cron test meldet danach „WP-Cron spawning is disabled“.

• systemd-Einheiten unter /etc/systemd/system/, Quellen infra/kisp-wp-cron.service und infra/kisp-wp-cron.timer. Der Dienst führt aus:

docker compose -p kisp run --rm -T wpcli wp cron event run --due-now

Der Timer startet 2 Minuten nach dem Boot und danach alle 5 Minuten.

• Aktivieren und prüfen:

systemctl daemon-reload
systemctl enable --now kisp-wp-cron.timer
systemctl start kisp-wp-cron.service
journalctl -u kisp-wp-cron.service -n 20 --no-pager
systemctl list-timers kisp-wp-cron.timer --no-pager

• Action Scheduler: Der Befehl heißt wp action-scheduler action list --status=pending. Er arbeitet über das Cron-Ereignis action_scheduler_run_queue.
• Beleg für den Timer: Das Backend zeigte „4 past-due actions“ (Termine 2026-10-04, 07:57 bis 09:46 UTC). Nach dem ersten Timer-Lauf standen alle vier auf complete, failed war leer, die Meldung verschwand. Zwei wiederkehrende Aktionen sind neu eingeplant:

docker compose -p kisp run --rm wpcli wp action-scheduler action list --status=pending --fields=id,hook,scheduled_date
docker compose -p kisp run --rm wpcli wp action-scheduler action list --status=complete --fields=id,hook,scheduled_date
docker compose -p kisp run --rm wpcli wp action-scheduler action list --status=failed --fields=id,hook,scheduled_date

• TODO: Die Aktionen wp_umbrella_* stammen von WP Umbrella. Ob auch die Bibliothek Action Scheduler von diesem Plugin mitgebracht wird, ist offen.
• TODO: Offen ist, ob bei aktivem WP-Cron der Selbstaufruf an Caddy mit 401 scheitern würde. Die Annahme ist plausibel, getestet wurde sie nicht.

• Stack kisp unter /data/terruhn.it/kisp/ mit compose.yaml und .env (Rechte 600).
• Dienste: wordpress (wordpress:php8.3-apache), db (mariadb:11.4), wpcli (wordpress:cli, Profil tools, startet nur bei Bedarf).
• Netze: kisp_internal (internal: true, nur WordPress und Datenbank), das Standardnetz für Internetzugang ausgehend, terruhn_proxy (extern) für Caddy.
• Keine veröffentlichten Ports. Zusätzlicher Mount /data/terruhn.it/kisp/staging als Exportziel für Etappe 03.
• Verzeichnisse und Rechte:

mkdir -p /data/terruhn.it/kisp/{wordpress,db,staging}
chown 33:33 /data/terruhn.it/kisp/wordpress /data/terruhn.it/kisp/staging
cd /data/terruhn.it/kisp && docker compose -p kisp up -d

• Konfiguration im Repository unter infra/: compose.yaml, .env.example, Caddyfile-kisp.

• Hash erzeugen: docker exec -it caddy caddy hash-password.
• Site-Block (Hash nur auf dem Server eintragen, nicht ins Repository):

wordpress.thekeepitsimpleproject.org {
    encode zstd gzip
    log

    @geschuetzt not {
        remote_ip 212.83.142.5
        header_regexp ua User-Agent ^WPUmbrella
    }

    basic_auth @geschuetzt {
        rene HASH_HIER
    }
    reverse_proxy kisp-wp:80
}

• Der Matcher @geschuetzt trifft alle Anfragen außer denen von WP Umbrella (Absenderadresse 212.83.142.5 und User-Agent ^WPUmbrella). Nur dort entfällt die Passwortabfrage. Das Plugin sichert seine Routen selbst mit Token und Signatur. Weitere Absenderadressen von WP Umbrella sind möglich (unbekannt); neue 401-Zeilen im Log zeigen sie an.
• Prüfen und laden:

docker exec caddy caddy validate --config /etc/caddy/Caddyfile
docker exec caddy caddy reload --config /etc/caddy/Caddyfile

• Zertifikat von Let’s Encrypt über den HTTP-Challenge, Ports 80 und 443 vom Router auf den Cube weitergeleitet.
• Stolperstein: Caddy sieht jede Anfrage mit 172.18.0.1 (Docker-Gateway). Eine remote_ip-Beschränkung auf das LAN greift deshalb nicht und lässt alles durch. Lesbar mit log im Site-Block und docker logs caddy | grep '"host":"wordpress' | grep -o '"remote_ip":"[^"]*"'.

• Plugin aus dem WordPress-Verzeichnis installieren, API-Schlüssel eintragen.
• Befund: Die Felder für die HTTP-Auth-Zugangsdaten erscheinen nur, wenn eine .htpasswd neben einer .htaccess liegt. Der Schutz liegt hier in Caddy, daher fehlten sie. Ein Must-Use-Plugin blendet sie über den Filter wp_umbrella_has_htpasswd ein:

mkdir -p /data/terruhn.it/kisp/wordpress/wp-content/mu-plugins
vi /data/terruhn.it/kisp/wordpress/wp-content/mu-plugins/kisp-umbrella-httpauth.php
chown -R www-data:www-data /data/terruhn.it/kisp/wordpress/wp-content/mu-plugins

Inhalt: add_filter('wp_umbrella_has_htpasswd', '__return_true');

• Befund: Die Anfragen der WP-Umbrella-Server trugen die Zugangsdaten dennoch nicht mit und liefen auf 401. Daher die Ausnahme im Caddyfile (oben).
• Absender im Log prüfen:

docker logs caddy --since 5m 2>&1 | grep '"remote_ip":"212.83.142.5"' | jq -r '[(.ts|todate), .request.method, .request.uri[0:70], .status] | @tsv'

• Uptime-Monitor bleibt deaktiviert, die Synchronisierung läuft.

cd /data/terruhn.it/kisp
docker compose -p kisp run --rm wpcli wp core version
docker compose -p kisp run --rm wpcli wp core is-installed 2>/dev/null; echo "Exit: $?"
docker compose -p kisp run --rm wpcli wp theme list --status=active --field=name
docker compose -p kisp run --rm wpcli wp plugin list --format=count

wp core is-installed schreibt keine Meldung, das Ergebnis steckt im Exit-Code (0 installiert, 1 nicht). Stand dieser Etappe: WordPress 7.1.2, Theme twentytwentyfive, 0 Plugins. Die Warnung zu HTTP_HOST stammt aus der Konfiguration ohne Webanfrage und ist harmlos.

Angriffe im Log nach uri zählen:

docker logs caddy --since 24h 2>&1 | grep '"host":"wordpress' | grep -o -E '"uri":"[^"]*"' | sort | uniq -c | sort -rn | head