Fortgeschritten

cipi api

Cipi kann optional eine REST API-Schicht auf dem Server aktivieren über cipi api <domain>. Die Stromversorgung erfolgt über das Laravel-Paket cipi/api (aktuelle Version 1.20), was Folgendes aufdeckt:

• RUHE API — Apps (einschließlich Octane erstellen, .env, auth.json, Artisan, auf der Whitelist app run, Deploy-Config), Aliase, www Weiterleitungen, Bereitstellung, SSL, Multi-Engine-Datenbanken, App-Protokolle, Serverstatus (/api/*)
• MCP Server — Über 50 Werkzeuge bei /mcp (Streamable HTTP)
• Server-Cockpit — PHP Installation/Switch, SSH-Schlüssel, Dienste, SMTP, Healthchecks, IP-Whitelist (API 1.15.0+ / Cipi 5.0.6+)
• Swagger-Benutzeroberfläche— interaktive Referenz unter/docs

Erfordert PHP 8.2+ und Laravel 12+ auf dem Panel-Host. Das ist Serverebene Automatisierung – anders als pro AppCipi Agent Paket (cipi/agent pro Laravel App).

Die cipi/api Paket

Auf einem normalen Cipi-Server installieren Sie das Paket nie manuell – cipi api <domain> Rückstellungen Laravel bei /opt/cipi/api, Nginx, SSL, SQLite-Jobwarteschlange und cipi-queue.service. Als Referenz oder benutzerdefinierte Setups:

$ composer require cipi/api
$ php artisan vendor:publish --tag=cipi-config
$ php artisan vendor:publish --tag=cipi-assets
$ php artisan migrate
$ php artisan cipi:seed-api-user
$ php artisan cipi:token-create

Panel .env verwendet CIPI_APPS_JSON=/etc/cipi/apps.json (oder apps-public.json Projektion für nicht empfindliche Felder). Token-Fähigkeiten sind in definiertconfig/cipi.php — list them with php artisan cipi:token-abilities (gleich Liste als cipi api token create seit Cipi 4.6.3).

Quelle und Changelog: github.com/cipi-sh/api (MIT). Client-Wrapper: cipi-cli.

Befehle

$ cipi api <domain>           # configure API at root (e.g. api.myhosting.com)
$ cipi api ssl                  # install Let's Encrypt certificate for API domain
$ cipi api token list           # list tokens
$ cipi api token create         # create a new token (choose abilities)
$ cipi api token revoke <id>    # revoke a token
$ cipi api status               # Laravel + cipi-api versions, queue worker, pending jobs, FPM pool
$ cipi api fix-permissions      # repair panel storage/database ownership (www-data)
$ cipi api update               # soft update: composer update on Laravel and API packages
$ cipi api upgrade              # full rebuild with rollback at /opt/cipi/api.old

Panel API Fehlerbehebung

Nachher cipi self-update, Root-eigene Dateien unter /opt/cipi/api oder/opt/cipi/gui kann PHP-FPM verhindern (www-data) vom Schreiben von Protokollen oder dem SQLite-Jobdatenbank – der Browser zeigt eine leere Datei an HTTP 500 auf /docs oder/mcp. Cipi repariert den Besitz normalerweise automatisch während der Selbstaktualisierung (Migration). 5.0.13+ fordert API/GUI Eigentum zurück); Wenn die Probleme weiterhin bestehen:

$ cipi api fix-permissions   # chown storage, database, bootstrap/cache, .env → www-data
$ cipi api status              # confirm Laravel version, queue worker, pending jobs

cipi api status druckt die installierten Laravel und cipi/api Paketversionen, ob cipi-queue.service ist aktiv, ausstehende asynchrone Jobs in der Panel-SQLite-Datenbank, und PHP-FPM-Poolstatistiken für den API vhost (einschließlich langsamer Anfragen, wenn konfiguriert). cipi api update führt ein Soft-Update des Panel API-Pakets von Packagist durch (seit 5.0.15; Durch die Migration werden veraltete VCS-Repo-Einträge gelöscht. cipi api upgrade führt einen vollständigen Neuaufbau mit Rollback durch /opt/cipi/api.old. Seitdem 5.0.14–5.0.17, Selbstaktualisierung verwendet zeitgesteuerte GitHub-Tarballs und Packagist-Dist installiert, anstatt Composer VCS-Klone für API- und GUI-Pakete zu blockieren. Seitdem 5.0.18, GUI Upgrade/Update vermeidet Composer Symlinks, die PHP-FPM beschädigen open_basedir (HTTP 500); laufen cipi gui fix-permissions odercipi self-update zur Reparatur vorhandener Paneele.

Seitdem v4.7.18 (Migrationen 4.7.15–4.7.18), Panel API Ausfälle am Ubuntu 25.10+ / 26.04 sind durchgängig fixiert: sudo-rs Ausschuss cipi db restore * * Platzhalter (die gesamte sudoers-Datei wurde ignoriert – Ich fürchte, das kann ich nicht), daher verwendet die Whitelist Trailing * nur; Beschaffung common.shbricht schreibgeschützte Befehle nicht mehr ab, wenn /etc/cipi wird schreibgeschützt erneut gemountet; API open_basedir beinhaltet /usr/local/bin/ für Holzhelfer; und cipi db list zeigt leere Datenbanken an und zeigt Sprung-/MariaDB-Fehler an. Lauf cipi self-update bewerben.

Token-Erstellung und detaillierte Berechtigungen

Authentifizierung verwendet Heiligtum. Jeder Token kann einen oder mehrere haben Fähigkeiten das Beschränken Sie die zulässigen Vorgänge:

• apps-view– Apps lesen
• apps-create – Apps erstellen
• apps-edit – Apps bearbeiten (PHP, Repository, Zweig, primäre Domäne seit API 1.9.0+ / Cipi 4.6.2+)
• apps-suspend – Apps anhalten und wieder freigeben
• apps-basicauth – Aktivieren, deaktivieren und überprüfen Sie HTTP Basic Auth für Apps (API 1.10.0+)
• apps-env — list/merge app .env Tasten (API 1.14.0+ / Cipi 5.0.3+)
• apps-auth — gemeinsame Composer verwalten auth.json (API 1.14.0+; verschieden von apps-basicauth)
• apps-artisan — Führen Sie Artisan als asynchronen Job aus (API 1.14.0+)
• apps-run – Nicht interaktiv auf die Whitelist gesetzt app run (API 1.14.0+)
• apps-deploy-config — strukturierte Deployer-Rezeptoptionen (API 1.14.0+)
• php-view — Liste der installierten PHP-Versionen (API). 1.15.0+)
• php-manage — PHP installieren/entfernen, Systemstandard festlegen (API 1.15.0+ / 1.17.0+ für PUT /api/php/default)
• ssh-view – SSH-Schlüssel auflisten cipi Benutzer (API 1.15.0+)
• ssh-manage — SSH-Schlüssel hinzufügen/entfernen/umbenennen (API 1.15.0+)
• services-view — Systemdienste auflisten (API 1.15.0+)
• services-manage — Dienste neu starten (API 1.15.0+)
• smtp-view — SMTP-Benachrichtigungseinstellungen lesen (Passwort wird nie zurückgegeben; API 1.15.0+)
• smtp-manage — SMTP konfigurieren, aktivieren, deaktivieren, testen, löschen (API 1.15.0+)
• health-view — Gesundheitschecks auflisten (API 1.15.0+)
• health-manage – Gesundheitschecks pro App festlegen, deaktivieren und ausführen (API 1.15.0+)
• ip-whitelist-view — Lesen Sie Panel API / MCP IP-Zulassungsliste (API1.15.0+)
• ip-whitelist-manage — IP-Zulassungslisteneinträge bearbeiten (API 1.15.0+)
• apps-delete – Apps löschen
• deploy-manage – Bereitstellen, Rollback, Entsperren
• ssl-manage — SSL-Zertifikate installieren und verwalten
• aliases-view – Aliase lesen
• aliases-create – Aliase hinzufügen
• aliases-delete – Aliase entfernen
• www-manage — www/apex-Gegenstück und Weiterleitungen (API 1.12.0+ / Cipi 4.8+)
• dbs-view — Datenbanken auflisten
• dbs-create — create databases
• dbs-delete— Datenbanken löschen
• dbs-manage — Passwort sichern, wiederherstellen, neu generieren
• status-view — Serverstatus-Snapshot lesen (GET /api/status, API 1.11.6+)
• mcp-access — Greifen Sie auf den MCP-Server zu

Seit Cipi 4.6.3 / API 1.11.7+, cipi api token create liest die kanonische Fähigkeitsliste aus dem Panel API-Paket (gleiche Einträge wie php artisan cipi:token-abilities auf dem Server). Migration 4.6.3 rüstet bestehende Server mit der aktualisierten Liste nach (inkl status-view, apps-suspend, und apps-basicauth).

REST-Endpunkte

Alle Endpunkte erfordern das Authorization: Bearer <token> Kopfzeile. Schreiboperationen (Erstellen, Bearbeiten, Löschen, Bereitstellen, Rollback, Entsperren, SSL, Alias, www, Datenbank) sind asynchron: sie Rückkehr 202 Acceptedmit einem job_id to poll via GET /api/jobs/{id}. Schreibgeschützte Endpunkte wie z GET /api/dbs, GET /api/dbs/engines, GET /api/status, GET /api/apps/{name}/www, und GET /api/apps/{name}/logs (API 1.11.9+), GET /api/php, GET /api/ssh/keys, GET /api/services, GET /api/smtp, GET /api/health, GET /api/ip-whitelist (API 1.15.0+ / Cipi 5.0.6+) sind synchron. POST /api/apps accepts optional custom (boolean) und docroot (String-)Parameter zum Erstellen custom apps mit klassischer Bereitstellung. Die repository Feld ist erforderlich für Laravel Apps und optional für benutzerdefinierte Apps: Lassen Sie es weg (oder senden Sie es leer), um eine reine SFTP-Site bereitzustellen ausgerichtet auf Cipi v4.5.1+. Wenn kein Repository festgelegt ist, branch ist weggelassen. Seit API 1.12.0+ / Cipi 4.8+, Laravel app create akzeptiert auch optional engine (mariadb oder pgsql), um die Datenbank auszuwählen Motor. Seit API 1.13.0+ / Cipi 5.0+, Laravel App-Erstellung akzeptiert optional octane (true oder "frankenphp") zur Bereitstellung Laravel Octane (FrankenPHP); octane wird abgelehnt, wenn custom eingestellt ist. Das MCP-Tool AppCreate folgt den gleichen Regeln. Behalte die API Paket aktuell mit cipi api update / cipi api upgrade also Validierung und OpenAPI entspricht diesem Verhalten.

POST /api/apps/{name}/suspend Schaltet eine App offline, indem sie ihren Nginx vhost gegen einen austauscht generisch HTTP 503 Wartungsseite (HTTPS im Lieferumfang enthalten), ohne sie zu löschen POST /api/apps/{name}/unsuspend stellt den normalen vhost wieder her. Beide erfordern die apps-suspend Fähigkeit und Rendite 409 wenn die App bereits im Ziel ist Staat. Die suspended Flag überlebt die vhost-Regeneration und wird angezeigt GET /api/apps und GET /api/apps/{name}. Diese Endpunkte erfordern die API Paket 1.8.1+ und Cipi 4.5.8+ auf dem Server.

PUT /api/apps/{name} akzeptiert eine optionale Option domainFeld zum Umbenennen Die primäre Domäne der App. Seit API 1.15.0+ / Cipi 5.0.6+, die Endpunkt leitet nur Felder weiter, die sich von der aktuellen App unterscheiden (verhindert No-Op webhook oder Deploy-Key). Erholung, wenn PHP oder Zweig unverändert bleiben). PHP muss auf dem Host installiert sein (andernfalls 422). Der API validiert das Format synchron und gibt zurück 409 wenn die Domain bereits von einer anderen App verwendet wird (Aliase der aktuellen App sind erlaubt, also Förderung eines Alias für Primärwerke). Erfordert das API-Paket 1.9.0+ und Cipi 4.6.2+. Das MCP-Tool AppEdit akzeptiert das Gleiche domain Parameter.

GET /api/apps und GET /api/apps/{name} Booleschen Wert aussetzen suspended und basic_auth Flags pro App (von apps.json). Seit API 1.12.0+ they also expose engine, www_redirect, und force_https von apps-public.json / apps metadata. Since API 1.13.0+ sie entlarven octane und octane_port für Octane Apps.

HTTP Basic Auth-Endpunkte unten /api/apps/{name}/basicauth/* wickeln cipi basicauth synchron – sie geben kein a zurück job_id. Aktivieren akzeptiert optional user und password (wird automatisch generiert, wenn es weggelassen wird; wird einmal zurückgegeben die Antwort). Erfordert die apps-basicauth Fähigkeit und API-Paket 1.10.0+. Dies unterscheidet sich von Composer auth.json Management – siehe cipi basicauth.

WWW/Apex-Endpunkte unter /api/apps/{name}/www/* wickeln cipi www (API 1.12.0+ / Cipi 4.8+). GET …/www ist synchron und kehrt zurück primary, apex, www, und redirect. POST …/www/add, …/force-to-root, …/force-from-root, und …/clear sind asynchrone Jobs. Erfordert die www-manage Fähigkeit. MCP Werkzeuge: WwwStatus, WwwAdd, WwwForceToRoot, WwwForceFromRoot, WwwClear.

POST /api/apps/{name}/ssl/force wendet die Umleitung HTTP → HTTPS erneut an, ohne eine auszugeben neues Zertifikat (cipi ssl force). Erfordert ssl-manage und API 1.12.0+. MCP tool: SslForce.

GET /api/dbs listet Datenbanken synchron durch Ausführen auf sudo cipi db list auf dem Host (identisch mit dem Server CLI). Optionale Abfrage engine=mariadb|pgsql Filter nach Motor (API 1.12.0+ / Cipi 4.8+). GET /api/dbs/engines listet installierte Motoren und die auf Serverstandard (sync; MCP DbEngines). Andere /api/dbs/* Schreiboperationen sind asynchrone Jobs und akzeptieren optional engine beim Erstellen, Löschen, Sichern, Wiederherstellen, und Passwort. Datenbankbefehle erfordern Cipi 4.4.17+ auf dem Server (cipi db … Einträge in der API Sudoers-Whitelist); Multi-Engine-Unterstützung benötigt Cipi 4.8+.

POST /api/apps/{name}/webhook/recreate erstellt den GitHub/GitLab-Deploy webhook neu; optionaler Körper { "rotate_secret": true } dreht sich auch CIPI_WEBHOOK_TOKEN in apps.json und shared/.env. Asynchroner Job (app-webhook-recreate; Fähigkeit apps-edit; CLI cipi app webhook recreate [--rotate-secret]; API 1.15.0+ / Cipi 5.0.6+). MCP: AppWebhookRecreate.

PHP Verwaltung (API 1.15.0+ / Cipi 5.0.6+): GET /api/php listet installierte Versionen auf (Synchronisierung; Fähigkeit php-view). POST /api/php/install und DELETE /api/php/{version} a installieren oder entfernen Version (asynchron; php-manage). Seit API 1.17.0+, PUT /api/php/default Setzt den Systemstandard PHP synchron (Body { "version": "8.5" }; wickelt cipi php switch; Rückgaben aktualisiert GET /api/php Nutzlast). Installierbare Versionen sind 8.3, 8.4, 8.5. MCP: PhpList.

DB-Motoren — POST /api/dbs/engines/install und PUT /api/dbs/engines/default (Fähigkeitdbs-manage; API 1.15.0+).

SSH-Schlüssel — GET|POST /api/ssh/keys, DELETE /api/ssh/keys/{n} (Fähigkeiten ssh-view / ssh-manage; API 1.15.0+).

Dienstleistungen — GET /api/services, POST /api/services/{name}/restart (Fähigkeiten services-view / services-manage; API 1.15.0+).

SMTP — GET|PUT|DELETE /api/smtp, POST /api/smtp/enable|disable|test (Fähigkeiten smtp-view / smtp-manage; Passwort wurde bei GET nie zurückgegeben; API 1.15.0+ / Cipi 5.0.6+ nicht interaktiv cipi smtp configure --host=…).

Gesundheitschecks — GET /api/health, GET|PUT|DELETE /api/apps/{name}/health, POST /api/apps/{name}/health/check (Fähigkeiten health-view / health-manage; API 1.15.0+).

IP whitelist – Middleware cipi.ip auf api/* und /mcp liest /etc/cipi/api-ip-whitelist(fehlende Datei bzw* = alles zulassen). Abgelehnte Kunden erhalten 403 { "error": "IP not allowed", "ip": "…" }. AUSRUHEN:GET /api/ip-whitelist, PUT /api/ip-whitelist (entries, optional ensure_client_ip), POST /api/ip-whitelist (ip), DELETE /api/ip-whitelist (ip), POST /api/ip-whitelist/allow-all (Fähigkeiten ip-whitelist-view / ip-whitelist-manage; CLI cipi api ip-whitelist; API 1.15.0+ / Cipi 5.0.6+). MCP: IpWhitelistShow.

GET /api/status gibt das gleiche strukturierte JSON zurück wie cipi status (System, Ressourcen, Dienste, PHP-Pools, App-Anzahl). Seit API 1.11.8+ der Endpunkt bevorzugt sudo cipi statusauf dem Host und greift auf direkte Host-Lesevorgänge zurück, wenn sudo ist nicht verfügbar. Seit API 1.12.1+Der Host-Read-Fallback umfasst postgresql wenn das systemd-Gerät eingebaut ist (entsprechend Cipi 4,8+). Erfordert die status-view Fähigkeit (API 1.11.6+). Die MCP Werkzeug ServerStatus gibt die gleiche Nutzlast zurück und erfordert nur mcp-access. Verwenden Sie von Ihrem Laptop aus cipi-cli status für einen globalen Überblick über alle konfigurierte Serverprofile oder Details für ein Profil.

GET /api/apps/{name}/logs gibt synchrone, paginierte Protokoll-Snapshots für nginx zurück, PHP-FPM, Laravel (sofern vorhanden), Worker- und Bereitstellungsprotokolle – das REST-Gegenstück zu cipi app logs und cipi-cli apps logs. Abfrageparameter: type (Standard all), page (Standard 1, die meisten aktuell zuerst), per_page (Standard 50, max 1000). Erfordert die apps-view Fähigkeit und API-Paket 1.11.9+. Der Protokolltext wurde geschwärzt Gemeinsame Geheimnisse (gleiche Richtlinie wie MCP AppLogs seit API 1.11.5+).

REST-Beispiele (curl)

Legen Sie Ihre Basis-URL und Ihr Token für API fest (von cipi api token create):

exportieren CIPI_API_URL=„https://api.myserver.com“
exportieren CIPI_API_TOKEN=„Dein-Sanktum-Token“

Apps auflisten (synchronisieren, 200):

curl -sS „${CIPI_API_URL}/api/apps“ \
  -H „Autorisierung: Inhaber ${CIPI_API_TOKEN}“ \
  -H „Akzeptieren: Bewerbung/json“

Server status (synchronisieren, erfordert status-view):

curl -sS „${CIPI_API_URL}/api/status“ \
  -H „Autorisierung: Inhaber ${CIPI_API_TOKEN}“

App-Protokolle (synchronisieren, erfordert apps-view, API 1.11.9+):

curl -sS „${CIPI_API_URL}/api/apps/myapp/logs?type=deploy&page=1&per_page=50“ \
  -H „Autorisierung: Inhaber ${CIPI_API_TOKEN}“ \
  -H „Akzeptieren: Bewerbung/json“

Erstellen Sie eine Laravel Octane-App (async, API 1.13.0+ / Cipi 5.0+; requires apps-create):

curl -sS -X POST „${CIPI_API_URL}/api/apps“ \
  -H „Autorisierung: Inhaber ${CIPI_API_TOKEN}“ \
  -H „Akzeptieren: Bewerbung/json“ \
  -H „Content-Type: application/json“ \
  -d '{
    „domain“: „shop.example.com“,
    „repository“: „git@github.com:you/shop.git“,
    „Zweig“: „Haupt“,
    „octane“: wahr,
    „Motor“: „mariadb“
  }'

Senden "octane": "frankenphp"für den gleichen Effekt. Auslassenoctane für Klassiker PHP-FPM. Benutzen "engine": "pgsql" wenn PostgreSQL installiert ist (API 1.12.0+ / Cipi 4.8+).

App .env (sync, API 1.14.0+ / Cipi 5.0.3+; requires apps-env):

curl -sS „${CIPI_API_URL}/api/apps/myapp/env“ \
  -H „Autorisierung: Inhaber ${CIPI_API_TOKEN}“

curl -sS -X PUT „${CIPI_API_URL}/api/apps/myapp/env“ \
  -H „Autorisierung: Inhaber ${CIPI_API_TOKEN}“ \
  -H „Content-Type: application/json“ \
  -d '{"set":{"APP_DEBUG":"false"},"unset":["LEGACY_KEY"]}'

Artisan / App-Lauf (async jobs, API 1.14.0+; Fähigkeiten apps-artisan / apps-run):

curl -sS -X POST „${CIPI_API_URL}/api/apps/myapp/artisan“ \
  -H „Autorisierung: Inhaber ${CIPI_API_TOKEN}“ \
  -H „Content-Type: application/json“ \
  -d '{"command":"cache:clear"}'

curl -sS -X POST „${CIPI_API_URL}/api/apps/myapp/run“ \
  -H „Autorisierung: Inhaber ${CIPI_API_TOKEN}“ \
  -H „Content-Type: application/json“ \
  -d '{"command":"composer install --no-dev"}'

curl -sS „${CIPI_API_URL}/api/run-commands“ \
  -H „Autorisierung: Inhaber ${CIPI_API_TOKEN}“

Umfrage GET /api/jobs/{id} für output / exit_code. Jobtypen: app-artisan, app-run.

Stellen Sie eine App bereit (asynchron, 202 + job_id):

curl -sS -X POST „${CIPI_API_URL}/api/apps/myapp/deploy“ \
  -H „Autorisierung: Inhaber ${CIPI_API_TOKEN}“ \
  -H „Akzeptieren: Bewerbung/json“

# poll until completed
curl -sS „${CIPI_API_URL}/api/jobs/JOB_ID“ \
  -H „Autorisierung: Inhaber ${CIPI_API_TOKEN}“

Datenbanksicherung (asynchron, dbs-manage) – gibt einen echten Backup-Pfad zurück der Job result, kein anonymisierter Dump (siehe Agenten-Anonymisierer):

curl -sS -X POST „${CIPI_API_URL}/api/dbs/myapp_db/backup“ \
  -H „Autorisierung: Inhaber ${CIPI_API_TOKEN}“

Host-Integration (sudoers)

Das Panel API läuft wie folgt www-data und führt Cipi CLI Befehle aus sudo verwenden /etc/sudoers.d/cipi-api – eine explizite Whitelist von cipi Unterbefehle. Tresor- und MariaDB-Zugangsdaten bleiben in Cipi, nicht in PHP.

• GET /api/dbs – läuft sudo cipi db list (synchronisieren). Benötigt Cipi 4.4.17+ (Migration fügt hinzu cipi db … zu Sudoers). Ohne es: sudo: a terminal is required. Mehrmotorenliste/Motoren benötigen Cipi 4.8+ / API 1.12.0+.
• GET /api/status / MCP ServerStatus – lieber sudo cipi status (API 1.11.8+); Host-Lese-Fallback, wenn sudo fehlschlägt (beinhaltet postgresql seit API 1.12.1+).
• MCP ServiceList — sudo cipi service list
• MCP AppArtisan — sudo cipi app artisan <app> …
• Seit Cipi 5.0.6+ / API 1.15+: php list|install|remove|switch, ssh list|add|remove, service list|restart, status, db install|default|engines, app webhook recreate, smtp status|configure|enable|disable|test|delete, api ip-whitelist (+ args) in der Sudoers-Whitelist (Migration 5.0.6 erstellt die Standard-IP-Whitelist-Datei und generiert sie neu /etc/sudoers.d/cipi-api auf cipi self-update).
• Seit Cipi 5.0.3+ / API 1.14+: app env, app artisan, app run, auth create|edit|show|deleteund „deploy-config“ in der sudoers-Whitelist (Migration regeneriert /etc/sudoers.d/cipi-apiAncipi self-update).
• Asynchrone Jobs – cipi app(einschließlich--octane / --engine), deploy, alias, www, ssl / ssl force, db create|delete|backup|restore|password|enginesusw.

Nachher cipi self-update, lauf cipi api fix-permissions wenn /docs oder /mcp Rückgabe HTTP 500 (siehe Fehlersuche oben).

IP whitelist (CLI)

Seit Cipi 5.0.6+, beschränken Sie Panel API- und MCP-Clients nach Quell-IP. Standarddatei /etc/cipi/api-ip-whitelist ist * (alles zulassen). Eine IPv4/IPv6-Adresse oder CIDR pro Zeile (oder durch Kommas getrennt). --ips=).

$ cipi api ip-whitelist show
$ cipi api ip-whitelist add 203.0.113.10
$ cipi api ip-whitelist set --ips=203.0.113.0/24,2001:db8::/32
$ cipi api ip-whitelist allow-all
$ cipi api ip-whitelist show --json

REST-Äquivalente leben unter /api/ip-whitelist (API 1.15.0+). PUT Fügt die IP des Anrufers automatisch hinzu, wenn die Liste enger wird, es sei denn ensure_client_ip: false.

Swagger / OpenAPI

Eine interaktive Dokumentation finden Sie unter /docs (Swagger-Benutzeroberfläche). Die OpenAPI-Spezifikation lautet generiert auspublic/api-docs/openapi.json und deckt Apps ab (einschließlich Suspend, Suspendierung aufheben, Domain umbenennen, Basisauthentifizierung,.env, Composer auth.json, Artisan / App-Run-Jobs, Deploy-Config, paginierte Protokolle, WWW-Weiterleitungen, Octane Erstellen und mehrmotorig engine), Aliase, Bereitstellen, SSL (installieren + erzwingen HTTPS), Datenbanken (Motorenliste + optional engine auf Mutationen), Serverstatus, Jobabfrage mit strukturiert result Typen und MCP Werkzeugschemata. Aktuelle Paketversion API: 1.20.

MCP Server

Ein MCP (Model Context Protocol) Server ist verfügbar unter /mcp über Streambar HTTP. Seit API Paket 1.11.1+, ein Token mit dem mcp-accessFähigkeit ist ausreichend füralle MCP Tools – REST pro Endpunkt Fähigkeiten (apps-view, deploy-manage, apps-basicauth, www-manageusw.) sind nicht aktiviert /mcp. Der Server stellt bereitÜber 50 Werkzeuge für App, Alias, www, Datenbank, bereitstellen, SSL, HTTP Basic Auth, Serververwaltung (PHP, SSH, Dienste, SMTP, Gesundheit, IP-Whitelist), .env / auth.json / app-run / deploy-config, job polling, logs, Artisan, and server monitoring. Write operations that dispatch async jobs return a job_id – Umfrage mit JobShow (API 1.11.0+). Grundlegende Authentifizierungsaktionen und schreibgeschützte Tools werden synchron ausgeführt.

• Applications: AppList, AppShow, AppCreate (optional engine, octane), AppEdit, AppSuspend, AppUnsuspend, AppDelete, AppDeploy, AppDeployRollback, AppDeployUnlock, AppArtisan (Laravel Nur Apps; lehnt benutzerdefinierte Apps ab undtinker), AppEnvShow, AppEnvUpdate, AppAuthJson*, AppRun, AppRunCommands, AppDeployConfigShow, AppDeployConfigUpdate, AppWebhookRecreate (API 1.15.0+ / Cipi 5.0.6+; Frühere App-Tools erfordern API 1.14.0+ / Cipi 5.0.3+)
• Server management: PhpList, IpWhitelistShow (API 1.15.0+ / Cipi 5.0.6+)
• HTTP Basisauthentifizierung: AppBasicAuthStatus, AppBasicAuthEnable, AppBasicAuthDisable
• Aliase: AliasList, AliasAdd, AliasRemove
• WWW / Apex: WwwStatus, WwwAdd, WwwForceToRoot, WwwForceFromRoot, WwwClear (API 1.12.0+)
• Datenbanken: DbEngines, DbList, DbCreate, DbDelete, DbBackup, DbRestore, DbPassword (optional engine auf Liste/Mutationen; API 1.12.0+)
• SSL: SslInstall, SslForce (API 1.12.0+)
• Jobs & logs: JobShow(Status des asynchronen Jobs abfragen, analysiert result, und CLI Ausgang),AppLogs (Aktuelle App-Protokolle nach Typ: all, nginx, php, worker, deploy, laravel – das Gleiche wie cipi app logs; REST-Äquivalent: GET /api/apps/{name}/logs seit API 1.11.9+), ApiLogShow (aktuelle Laravel Protokolle für den Panel API Host)
• Server monitoring: ServerStatus (strukturiertes JSON-Matching GET /api/status / cipi status), ServiceList (Systemdienststatus über cipi service list)

Seit Cipi 4.6.3, das Panel API-Paket wird jede Nacht um Soft-Updates aktualisiert 04:30 über /etc/cron.d/cipi-api (cipi api update), also MCP und REST-Endpunkte bleiben ohne manuelle Eingriffe auf dem neuesten Stand.

Installation des MCP-Servers

Der MCP-Endpunkt ist optional und wird nur geladen, wenn das erforderliche MCP-Paket installiert ist. Um es zu benutzen von VS-Code, Cursor, oder Claude Desktop:

1. Konfigurieren Sie den API mit cipi api <domain> und cipi api ssl
2. Erstellen Sie ein Token mit cipi api token create und wählen Sie mindestens mcp-access
3. Fügen Sie den MCP-Server zu Ihrer Client-Konfiguration hinzu (siehe unten).

Cursor

Hinzufügen zu ~/.cursor/mcp.json (oder Cursor → Einstellungen → MCP):

{
  "mcpServers": {
    "cipi-api": {
      "type": "http",
      "url": "https://<your-api-domain>/mcp",
      "headers": {
        "Authorization": "Bearer <your-token>"
      }
    }
  }
}

Der Cursor verbindet sich nativ über HTTP – keine Brücke erforderlich.

VS-Code

VS Code (mit GitHub Copilot) unterstützt MCP nativ seit 1.102. Hinzufügen zu .vscode/mcp.jsonoder laufenMCP: Benutzerkonfiguration öffnen für ein globales Setup. Benutzen inputs So fordern Sie das Token einmal an und speichern es sicher:

{
  "inputs": [
    {
      "type": "promptString",
      "id": "cipi-token",
      "description": "Cipi API Token",
      "password": true
    }
  ],
  "servers": {
    "cipi-api": {
      "type": "http",
      "url": "https://<your-api-domain>/mcp",
      "headers": {
        "Authorization": "Bearer ${input:cipi-token}"
      }
    }
  }
}

Starten Sie VS Code nach dem Speichern neu. Benutzen MCP: Server hinzufügen aus der Befehlspalette für a geführte Einrichtung.

Claude Code

Fügen Sie den MCP-Server direkt vom CLI hinzu:

$ claude mcp add --transport http cipi-api https://<your-api-domain>/mcp \
    --header "Authorization: Bearer <your-token>"

Claude Desktop

Claude Desktop benötigt dasmcp-Fernbedienung Bridge, um stdio in HTTP zu konvertieren. Hinzufügen zu ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) oder die Äquivalent Konfigurationspfad auf Ihrem Betriebssystem:

{
  "mcpServers": {
    "cipi-api": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://<your-api-domain>/mcp",
        "--header",
        "Authorization: Bearer <your-token>"
      ]
    }
  }
}

Installieren mcp-remote once with npm install -g mcp-remote.

Ersetzen <your-api-domain> mit Ihrer API-Domain (z.B. api.myhosting.com) und <your-token> mit dem in Schritt 2 erstellten Token.

WHMCS-Modul

Ein Beamter WHMCS-Bereitstellungsmodul ist erhältlich unter github.com/cipi-sh/whmcs. Es überbrückt den WHMCS-Bereitstellungslebenszyklus mit dem Cipi REST API – und automatisiert die App-Erstellung. Löschung, SSL Zertifikate, Bereitstellungen und Konfigurationsänderungen für Ihre Hosting-Kunden. Keine Composer Abhängigkeiten; Das Modul ist ein eigenständiges Drop-In.

Anforderungen

• WHMCS 8.x (Bereitstellungsmodultyp „Server“)
• Cipi-Server mit aktiviertem API: cipi api <domain> und cipi api ssl
• Sanctum-Träger-Token mit den erforderlichen Fähigkeiten:

Installation

1. Kopieren modules/servers/cipi/ in Ihr WHMCS-Root:

   your-whmcs/
   └── modules/
       └── servers/
           └── cipi/
               ├── cipi.php
               └── lib/
                   └── CipiApiClient.php

2. In WHMCS Admin → Systemeinstellungen → Server → Neuen Server hinzufügen:
   • Typ: Cipi (Laravel Hosting)
   • Hostname: API Basis-URL (z. B. https://api.example.com, nein abschließender Schrägstrich)
   • Passwort: Inhabertoken von cipi api token create
   • Sicher: Ja (empfohlen – ermöglicht die TLS-Verifizierung)
3. Erstellen Sie eine Hosting-Produkt mit diesem Server verknüpfen und konfigurieren Modul Einstellungen:

App-Typen

Bereitstellungslebenszyklus

Suspend / Unsuspend erfordern Cipi 4.5.8+ (Suspendieren/Suspendieren aufheben Endpunkte), das API-Paket 1.8.1+, und ein Token mit dem apps-suspend Fähigkeit. Durch das Anhalten wird der Vhost der App gegen eine generische 503-Wartungsseite für HTTP ausgetauscht. Durch die Aufhebung der Suspendierung wird es wiederhergestellt.

Admin-Schaltflächen

In der Verwaltungsdienstansicht des WHMCS können Bediener Ein-Klick-Aktionen auslösen:

Auto-SSL bei der Erstellung

Aktivieren Auto SSL in den Produktmoduleinstellungen, um automatisch eine zu installieren Lassen Sie uns das Zertifikat direkt nach der Bereitstellung verschlüsseln. Wenn die Installation SSL fehlschlägt, ist die App fehlgeschlagen weiterhin erfolgreich erstellt und es wird eine Warnung protokolliert.

Vollständiger API-Client

The bundled CipiApiClient deckt die gesamte Cipi REST API Fläche ab. Auch wenn es ein Feature ist nicht mit einem WHMCS-Hook verbunden ist, können Sie den Client in benutzerdefinierten Hooks oder Add-ons verwenden:

Erweiterung des Moduls

// Example: add an alias from a WHMCS hook
require_once ROOTDIR . '/modules/servers/cipi/lib/CipiApiClient.php';

$client = neu CipiApiClient('https://api.example.com', $token);
$client->addAlias('meine App', 'alias.example.com');

// Example: create an extra database
$client->createDatabase('myapp_extra');

// Example: backup a database
$client->backupDatabase('meine App');

Kundenorientiertes Verhalten

Das Modul tut es nicht Fügen Sie ab Cipi eine Registerkarte „Kundenbereich“, benutzerdefinierte Schaltflächen oder einen Live-Status hinzu. Kunden sehen die standardmäßige WHMCS-Serviceansicht (Domäne, Status, Verlängerungsdaten). Wenn Cipi eine App bereitstellt, wird sie generiert einmalige Geheimnisse (SSH-Passwort, DB Passwort, Bereitstellungsschlüssel, webhook URL). Der REST API überträgt diese Geheimnisse nicht automatisch in WHMCS – Sie sollten das Modul erweitern, einen Hook schreiben oder Anmeldeinformationen über Ihren Support-Workflow bereitstellen.

Modulprotokollierung

Alle API Anrufe werden über protokolliert logModuleCall() — Paket erstellen, beenden, ändern, SSL, Bereitstellung, Rollback, Entsperren und App-Info. Aktivieren Dienstprogramme → Protokolle → Modul Protokoll in WHMCS Admin für vollständige Sichtbarkeit.

cipi sync

Übertragen, replizieren und sichern Sie ganze Laravel Anwendungen zwischen Cipi Servern – einschließlich Konfiguration, Datenbank-Dumps, Speicherdateien, SSH-Schlüssel, Worker und Crontabs. Jedes Archiv ist verschlüsselt mit AES-256-CBC und durch eine benutzerdefinierte Passphrase geschützt, also Anmeldeinformationen und sensible Daten sind im Ruhezustand und während der Übertragung sicher.

Befehlsübersicht

$ cipi sync export  [app ...] [--with-db] [--with-storage] [--output=<path>] [--passphrase=<secret>]
$ cipi sync import  <archive.tar.gz.enc> [app ...] [--update] [--deploy] [--yes] [--passphrase=<secret>]
$ cipi sync push    [app ...] [--host=IP] [--port=22] [--with-db] [--with-storage] [--import] [--passphrase=<secret>]
$ cipi sync list    <archive.tar.gz.enc> [--passphrase=<secret>]
$ cipi sync pubkey  # display the server's sync public key for inter-server trust
$ cipi sync trust   # add a remote server's public key to cipi's authorized_keys

Archive encryption

Alle Synchronisierungsarchive sind standardmäßig verschlüsselt mit AES-256-CBC. Während des Exports sind Sie Sie werden zur Eingabe einer Passphrase (mindestens 8 Zeichen) aufgefordert, die das Archiv schützt. Die gleiche Passphrase ist erforderlich, um es zu importieren oder zu prüfen. Dies schützt SSH-Schlüssel, .envDateien, Datenbank-Dumps, und Anmeldeinformationen im Ruhezustand und während der Übertragung.

# Interactive mode (default) — prompted for passphrase
$ cipi sync export --with-db
#   Enter passphrase to encrypt the archive: ********
#   Confirm passphrase: ********

# Non-interactive mode — for cron jobs and scripts
$ cipi sync export --with-db --passphrase="MyStr0ngP@ss"

Exportieren

Packt App-Konfigurationen in eine verschlüsselte Datei .tar.gz.enc Archiv. Enthält optional eine Datenbank Dumps und Speicherdateien.

# Export all apps (config only)
$ cipi sync export

# Export three specific apps with database + storage
$ cipi sync export shop blog api --with-db --with-storage

# Export to a custom path (non-interactive)
$ cipi sync export --with-db --output=/root/backups/cipi-march.tar.gz --passphrase="MyStr0ngP@ss"

Was kommt ins Archiv?

Plus globale Konfigurationen: apps.json (gefiltert nach ausgewählten Apps), databases.json, backup.json, api.json.

Importieren

Stellt Apps aus einem Archiv auf dem aktuellen Server wieder her.

# Import all apps from archive
$ cipi sync import /tmp/cipi-sync-aws01-20260306.tar.gz.enc

# Import only two apps from an archive that contains ten
$ cipi sync import /tmp/cipi-sync-aws01-20260306.tar.gz.enc shop blog --passphrase="MyStr0ngP@ss"

# Import and deploy code from Git immediately
$ cipi sync import /tmp/cipi-sync-aws01-20260306.tar.gz.enc --deploy

# Non-interactive (skip all prompts)
$ cipi sync import /tmp/cipi-sync-aws01-20260306.tar.gz.enc --yes --passphrase="MyStr0ngP@ss"

Was der Import für eine NEUE App bewirkt

Wenn eine App auf dem Zielserver nicht vorhanden ist, wird sie durch den Import von Grund auf neu erstellt – äquivalent zu cipi app create mit allen aus dem Archiv vorausgefüllten Konfigurationen:

1. Linux-Benutzer — Erstellt einen neuen Benutzer mit einem zufälligen Passwort
2. Verzeichnisse – Erstellt /home/<app>/shared/, logs/, .ssh/, .deployer/
3. SSH-Bereitstellungsschlüssel — Stellt aus dem Archiv wieder her (gleicher Schlüssel funktioniert mit GitHub/GitLab). ohne Neukonfiguration)
4. MariaDB Datenbank — Erstellt Datenbank + Benutzer mit a neuer Zufall Passwort
5. Database data– Importiert den Dump, wenn --with-db wurde während verwendet exportieren
6. .env— Kopien aus dem Archiv also überschreibt DB_PASSWORD, DB_USERNAME, DB_DATABASE, DB_HOST mit den Werten des neuen Servers. Alles andere (APP_KEY, MAIL_*, REDIS_*, benutzerdefinierte Variablen) bleibt unverändert
7. PHP-FPM-Pool, Nginx Vhost, Supervisor Worker, Crontab, Deployer – Vollständig aus Archivdaten konfiguriert

Sicherheitskontrollen vor dem Import

Der Import führt vor dem Flug Prüfungen durch, bevor er etwas berührt:

• App already exists — blocked unless --update ist bestanden
• Domänenkonflikt – blockiert, wenn eine andere App bereits dieselbe Domäne verwendet
• Fehlende PHP-Version — Warnung (die App wird übersprungen; installieren Sie zuerst die Version mit cipi php install)

Update mode (--update)

Die Schlüsselfunktion für repeated sync (z. B. Failover-Replikation). Ohne --update, Import weigert sich, bereits vorhandene Apps zu berühren. Mit --update, es Aktualisierungen existing apps and schafft neue.

$ cipi sync import /tmp/archive.tar.gz.enc --update --passphrase="MyStr0ngP@ss"

Was bewirkt ein Update für eine vorhandene App?

• .env synchronisieren — Das Archiv .enversetzt das lokale, aber DB_PASSWORD, DB_USERNAME, DB_DATABASE, und DB_HOST sind vom lokalen Server gespeichert. Alles andere (APP_KEY, MAIL_*, REDIS_*, benutzerdefinierte Variablen) kommt von der Quelle.
• Database data — Wenn das Archiv einen Dump hat, werden alle Tabellen gelöscht (mit SET FOREIGN_KEY_CHECKS=0) und Reimporte. Verwendet lokale Root-Anmeldeinformationen.
• Lagerung – Wenn das Archiv über Speicher verfügt, werden Extrahierungen über das vorhandene Verzeichnis durchgeführt (neu). Dateien hinzugefügt, vorhandene überschrieben).
• PHP Versionsmigration — Wenn die Quelle eine andere PHP-Version verwendet, das Update migriert FPM-Pool, supervisor, Crontab, Deployer und .env automatisch.
• Nginx vhost, Supervisor Worker, Deployer-Konfiguration – Aus dem Archiv neu generiert Daten.
• Bereitstellen – Wenn --deploy übergeben wird, läuft dep deploy zu ziehen neuester Code.

Welches Update ändert sich NICHT?

• Linux user password
• SSH-Bereitstellungsschlüssel (behalten vom ersten Import an)
• MariaDB Benutzeranmeldeinformationen (Ziel behält seine eigenen)
• SSL Zertifikate (Lauf cipi ssl install separately)

Liste (Archiv prüfen)

Sehen Sie, was sich in einem Archiv befindet, ohne etwas zu importieren.

$ cipi sync list /tmp/cipi-sync-aws01-20260306.tar.gz.enc --passphrase="MyStr0ngP@ss"

Cipi Archiv synchronisieren
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Cipi v5.1.0
  Exportiert 2026-03-06T15:00:00Z
  Quelle aws01 (3.120.xx.xx)
  Datenbank wahr
  Lagerung wahr
 
  Apps
  APP-DOMÄNE PHP DB-SPEICHER
  shop shop.example.com 8.4 ja ja
  Blog blog.example.com 8.4 ja ja
  api api.example.com 8,5 ja ja
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Push (Export + Transfer + Import)

Kombiniert Export, Rsync-Übertragung und Remote-Import in einem Befehl. Läuft vollständig von der Quelle Server.

# Interactive push — prompted for target IP and passphrase
$ cipi sync push --with-db --with-storage --import

# Non-interactive push (for cron and scripts)
$ cipi sync push --host=51.195.xx.xx --port=22 --with-db --with-storage --import --passphrase="MyStr0ngP@ss"

# Push specific apps only
$ cipi sync push shop blog --host=51.195.xx.xx --with-db --import --passphrase="MyStr0ngP@ss"

# Push without auto-import (transfer only — import manually on remote)
$ cipi sync push --host=51.195.xx.xx --with-db --passphrase="MyStr0ngP@ss"

So funktioniert Push

1. Schritt 1: Läuft cipi sync export lokal (verschlüsselt mit Passphrase)
2. Schritt 2: Überträgt das verschlüsselte Archiv per rsync an das Ziel
3. Schritt 3: Wenn --import übergeben wird, läuft cipi sync import --update --yes auf dem Ziel per SSH

Push fügt immer hinzu --update und --yes beim Aufruf von import auf der Fernbedienung. Dies bedeutet: Beim ersten Durchlauf werden alle Apps erstellt, bei nachfolgenden Durchläufen werden sie inkrementell aktualisiert. Das ist es, was macht schieben sicher, wiederholt über cron zu laufen.

SSH setup for push

Der Quellserver benötigt SSH-Zugriff auf das Ziel cipi Benutzer. Nutzen Sie die integrierte Vertrauensmechanismus für passwortlose, schlüsselbasierte Authentifizierung zwischen Cipi Servern:

# On the SOURCE server — display its sync public key
$ cipi sync pubkey

# On the TARGET server — add the source's public key to cipi's authorized_keys
$ cipi sync trust

Einmal vertrauenswürdig, cipi sync push verbindet als die cipi Benutzer automatisch – kein Root-Zugriff erforderlich.

Practical scenarios

Szenario 1: Alle Apps von AWS zu OVH migrieren

Sie haben 20 Apps auf AWS. Sie haben einen OVH VPS gekauft und Cipi darauf installiert.

# On AWS (source server)
$ cipi sync push --host=51.195.xx.xx --with-db --with-storage --import

Auf dem OVH-Ziel: 20 Linux-Benutzer, 20 Datenbanken, 20 nginx Vhosts, PHP-FPM-Pools, supervisor Konfigurationen, Crontabs – alles automatisch erstellt. DB-Daten importiert, Speicher extrahiert, .env Dateien mit den DB-Passwörtern von OVH kopiert, SSH-Bereitstellungsschlüssel bleiben erhalten (gleiche Schlüssel funktionieren mit GitHub). Nachher importieren, Installieren Sie SSL und aktualisieren Sie DNS:

# On OVH (target server)
$ cipi ssl install shop
$ cipi ssl install blog
# ... then update DNS A records to OVH IP

Szenario 2: Geplante Failover-Replikation (cron)

Alle 6 Stunden synchronisiert Server 1 alle Apps mit Server 2. Wenn Server 1 ausfällt, ändern Sie DNS und gehen Sie live weiter Server 2.

# One-time setup on Server 1 — trust Server 2 using cipi sync trust
$ cipi sync pubkey  # copy this key, then run "cipi sync trust" on Server 2
$ echo "YourStr0ngPassphrase!" > /etc/cipi/.sync_passphrase
$ chmod 400 /etc/cipi/.sync_passphrase

# First push (manual, to verify)
$ cipi sync push --host=server2-ip --with-db --with-storage --import --passphrase="$(cat /etc/cipi/.sync_passphrase)"

# Add to crontab for automatic replication
$ crontab -e

0 */6 * * * /usr/local/bin/cipi sync push --host=51.195.xx.xx --port=22 --with-db --with-storage --import --passphrase="$(cat /etc/cipi/.sync_passphrase)" >> /var/log/cipi/sync-replica.log 2>&1

Das Datenverlustfenster entspricht dem cron-Intervall (in diesem Beispiel 6 Stunden). Wenn Server 1 ausfällt: ändern DNS auf Server 2, ausführen cipi ssl install für jede App, und Sie sind live.

Szenario 3: Replikation auf mehrere Server

# Stagger by 30 minutes so exports don't run simultaneously
0 */6 * * * /usr/local/bin/cipi sync push --host=51.195.xx.xx --with-db --with-storage --import --passphrase="$(cat /etc/cipi/.sync_passphrase)" >> /var/log/cipi/sync-ovh.log 2>&1
30 */6 * * * /usr/local/bin/cipi sync push --host=164.90.xx.xx --with-db --with-storage --import --passphrase="$(cat /etc/cipi/.sync_passphrase)" >> /var/log/cipi/sync-do.log 2>&1

Szenario 4: Tägliches verschlüsseltes Backup (keine Übertragung)

0 3 * * * /usr/local/bin/cipi sync export --with-db --with-storage --output=/root/backups/cipi-$(date +\%Y\%m\%d).tar.gz --passphrase="$(cat /etc/cipi/.sync_passphrase)" >> /var/log/cipi/export.log 2>&1

Erstellt jede Nacht ein verschlüsseltes tragbares Archiv. Wiederherstellen auf jedem Cipi-Server jederzeit mit cipi sync import.

Einschränkungen

• SSL Zertifikatesind nicht im Archiv enthalten. Lauf cipi ssl install nach dem Import auf einen neuen Server.
• Die DB-Synchronisierung ist ein vollständiger Ersatz, nicht inkrementell. Bei jedem Update werden alle Tabellen gelöscht und Reimporte.
• Die Speichersynchronisierung erfolgt vollständig, kein inkrementelles rsync. Gelöschte Dateien auf dem Quelle Bleiben Sie am Ziel.
• Schlüssel bereitstellen sind auf Quelle und Ziel gleich – kein GitHub/GitLab Neukonfiguration benötigt.

Vault & Encryption

Cipi verschlüsselt alle ruhenden Konfigurationsdateien mit AES-256-CBC. Das Vault-System Bietet transparente Verschlüsselung und Entschlüsselung, sodass vertrauliche Daten – Datenbankkennwörter, API Token, SSH-Schlüssel, .env Inhalte – werden niemals im Klartext auf der Festplatte gespeichert.

Architecture

Das System ist auf zwei Ebenen aufgebaut:

• Tresor — Transparente Verschlüsselung von JSON Konfigurationsdateien auf der Festplatte (server.json, apps.json, databases.json, backup.json, smtp.json, api.json)
• Verschlüsselung synchronisieren — Passphrasenbasierte Verschlüsselung von Exportarchiven für mehr Sicherheit Übertragung zwischen Servern

So funktioniert Vault

Bei der Installation wird ein Hauptschlüssel generiert openssl rand -base64 32 und gespeichert bei /etc/cipi/.vault_key (chmod 400, nur Root). Jede JSON Konfigurationsdatei ist auf der Festplatte verschlüsselt mit openssl enc -aes-256-cbc -salt -pbkdf2. Dateien behalten die .jsonErweiterung – der Inhalt ist einfach ein verschlüsselter Blob statt lesbarem JSON.

Die vault_read Die Funktion erkennt automatisch, ob eine Datei Klartext oder verschlüsselt (rückwärts) ist Kompatibilität), sodass vorhandene Server während des Updates nahtlos migriert werden.

Tresorfunktionen

# Core functions in lib/vault.sh
vault_init          # Generate .vault_key if not present
vault_read <file>   # Decrypt and output JSON to stdout (auto-detect plain/encrypted)
vault_write <file>  # Read JSON from stdin, encrypt and write to disk
vault_seal <file>   # Encrypt an existing plaintext file in-place
vault_get <file> <jq_query>  # Shortcut: vault_read | jq

Öffentliche Projektion

Cipi generates an apps-public.json Datei, die nur nicht sensible Felder enthält (Domäne, Aliase, PHP-Version, Zweig, Repository, Benutzer, Erstellungszeitstempel usw suspended und basic_auth Flaggen). Die cipi-api Gruppe liest Diese Klartextprojektion anstelle der verschlüsselten Datei, wodurch der Tresorschlüssel auf Root beschränkt bleibt.

Archivverschlüsselung synchronisieren

When you run cipi sync export, Konfigurationen werden aus dem Tresor in einen Staging-Bereich entschlüsselt, Anschließend wird das gesamte Archiv mit Ihrer Passphrase verschlüsselt. Beim Import wird das Archiv mit entschlüsselt Die Passphrase und die Konfigurationen werden mit dem neu verschlüsselt Tresor des Zielservers Schlüssel.

Email Notifications

Cipi kann E-Mail-Benachrichtigungen senden, wenn Sicherungsfehler, Bereitstellungsfehler, Systemjobfehler usw. auftreten es zu sicherheitsrelevanten Authentifizierungsereignissen kommt. Die SMTP-Konfiguration wird verschlüsselt gespeichert /etc/cipi/smtp.json und synchron eingebunden Exporte.

Befehle

$ cipi smtp configure      # interactive setup (Gmail, SendGrid, Mailgun, custom)
$ cipi smtp status          # display current notification settings
$ cipi smtp test            # send a verification email
$ cipi smtp enable          # enable notifications
$ cipi smtp disable         # disable without losing settings
$ cipi smtp delete          # remove SMTP configuration entirely

# Non-interactive (v5.0.6+) — panel API, scripts, automation
$ cipi smtp configure --host=smtp.example.com --port=587 --user=… --password=… \
    --from=alerts@example.com --to=ops@example.com --tls=on
$ cipi smtp status --json
$ cipi smtp delete --force

Detaillierte Benachrichtigungsauslöser

Seitdem v4.6.3können Sie steuern, bei welchen Ereignissen E-Mails gesendet werden, wenn SMTP konfiguriert ist. Alle Auslöser sind on by default; Ereignisse werden immer protokolliert /var/log/cipi/events.log regardless.

$ cipi notifications list              # all triggers grouped by category
$ cipi notifications enable <trigger>   # turn one trigger on
$ cipi notifications disable <trigger>  # turn one trigger off
$ cipi notifications enable-all          # re-enable everything
$ cipi notifications disable-all         # mute all email alerts
$ cipi notifications reset               # restore defaults (all on)

Konfiguration: /etc/cipi/notifications.json. Lauf cipi notifications list auf dem Server für den Live-Ein/Aus-Zustand. Trigger-IDs für cipi notifications enable|disable <trigger>:

v5.1.0 adds five: backup_stale (Ein Profil war innerhalb nicht erfolgreich das Doppelte seines eigenen Intervalls), ini_set (eine PHP-Einstellung geändert), yml_apply und yml_fail (ein Projekt cipi.yml angewendet wurde oder ungültig war) und self_update (Cipi hat sich selbst aktualisiert – daher landet kein unbeaufsichtigtes nächtliches Update mehr ohne ein Wort).

Automatische Benachrichtigungen

Nach der Konfiguration sendet Cipi E-Mail-Benachrichtigungen an:

• Sicherungsfehler (S3 Upload-Fehler, Dump-Fehler, ein beschädigtes Archiv) und seitdem v5.1.0, Backups, die einfach sind überfällig (backup_stale)
• Ergebnisse bereitstellen – seit v5.1.0 beide Erfolg undAusfall, ab dem CLI und das Git webhook gleichermaßen, mit dem Branch, der Release-Nummer, dem Commit, dem Autor, der Dauer und dem Gesundheitscheck-Urteil nach der Bereitstellung im Körper
• Eine Veröffentlichung, die fehlgeschlagen istnach der Bereitstellung Gesundheitscheck (deploy_health_fail), einschließlich eines automatischen Rollbacks habe es dagegen getan
• System cron Auftragsfehler (über die cipi-cron-notify Verpackung)
• App-Lebenszyklusereignisse – benachrichtigt, wenn eine App erstellt, bearbeitet oder gelöscht wird, einschließlich Server-Hostname, App-Name, Domäne und PHP-Version
• Sudo und su-Erhöhung – benachrichtigt, wenn ein Benutzer erfolgreich über erhöht wird sudo oder su, einschließlich wer es ausgeführt hat, Zielbenutzer (z su), SSH-Schlüssel, Client-IP und TTY
• Privilegierte SSH-Anmeldung – benachrichtigt, wenn root oder irgendein Sudoer meldet sich über SSH an, einschließlich Quell-IP, SSH-Schlüssel-Fingerabdruck und Schlüsselkommentar
• SSH-Schlüsseländerungen – benachrichtigt, wenn ein SSH-Schlüssel hinzugefügt, daraus entfernt oder umbenannt wird cipi Benutzer, einschließlich Hostname, IP, Fingerabdruck, Schlüsselkommentar, Zeitstempel und verbleibende Schlüsselanzahl. Umbenennungswarnungen enthalten auch den alten und neuen Schlüsselnamen.

Jede E-Mail-Benachrichtigung enthält eine Fußzeile mit der Client-IP (SSH_CLIENT) und das SSH Schlüsselname, der ggf. zur Authentifizierung verwendet wird. Der Schlüsselname wird über aufgelöst SSH_USER_AUTH mit einem auth.log Rückfall bei Bedarf.

Benachrichtigungen zur Sicherheitsauthentifizierung

Cipi integriert PAM-basierte Authentifizierungsbenachrichtigungen über pam_exec.so mit ExposeAuthInfo ermöglicht. Wenn SMTP konfiguriert ist, wird die Das System sendet automatisch E-Mail-Benachrichtigungen zu diesen sicherheitsrelevanten Ereignissen:

• Sudo und su Höhe – wird ausgelöst, wenn ein Benutzer erfolgreich ausgeführt wird sudo oder su. Die Benachrichtigung enthält den Benutzernamen, den Zielbenutzer (z su), TTY, SSH-Schlüssel, Client-IP und Zeitstempel.
• Privilegierter SSH-Login — triggered when root oder irgendein Benutzer in der sudo Gruppe meldet sich über SSH an. Die Benachrichtigung enthält den Benutzernamen und die Quell-IP Adresse, SSH-Schlüssel-Fingerabdruck und Schlüsselkommentar (aufgelöst von /var/log/auth.logFingerabdruckabgleich gegen authorized_keys).
• SSH-Schlüsseländerungen – wird ausgelöst, wenn ein SSH-Schlüssel hinzugefügt, entfernt oder hinzugefügt wird umbenannt am cipi Benutzer über cipi ssh add, cipi ssh remove, oder cipi ssh rename. Die Benachrichtigung enthält die Hostname, Server-IP, Schlüsselfingerabdruck, Schlüsselkommentar, Zeitstempel und verbleibende Schlüsselanzahl. Umbenennen Warnungen enthalten auch den alten und neuen Schlüsselnamen.
• Ereignisse im App-Lebenszyklus – wird ausgelöst, wenn eine App erstellt, bearbeitet oder gelöscht wird. Die Benachrichtigung enthält den Hostnamen des Servers, den App-Namen, die Domäne und die Version PHP.

Benachrichtigungen werden asynchron im Hintergrund ausgeführt, sodass die Anmeldung oder der Befehl nie verzögert wird Ausführung. Wenn SMTP nicht konfiguriert ist, schlagen die Hooks stillschweigend fehl, ohne dass sich dies auf das System auswirkt.

Security event log

Unabhängig von der SMTP-Konfiguration werden alle Benachrichtigungsereignisse (SSH-Schlüsseländerungen, App-Lebenszyklus, Passwort-Resets, sudo/su/SSH-Anmeldung, cron Fehler) werden immer protokolliert /var/log/cipi/events.log in einem kompakten einzeiligen Format. Der Stamm wird täglich mit gedreht 1 Jahr Aufbewahrung über Logrotate.

Cron Verpackung

Die cipi-cron-notify Das Dienstprogramm schließt System-Jobs ein und sendet eine Benachrichtigung, wenn der Job ausgeführt wird wird mit einem Code ungleich Null beendet. Dies ist nützlich für die Überwachung kritischer geplanter Aufgaben.

Protokollaufbewahrung (DSGVO)

Cipi erzwingt automatische Protokollrotationsrichtlinien, die der DSGVO und dem allgemeinen Datenschutz entsprechen Anforderungen. Protokolle werden automatisch rotiert und gelöscht – eine manuelle Bereinigung ist nicht erforderlich.

Valkey

Valkey ist der In-Memory-Datenspeicher, der als Teil des Standardstapels installiert wird. Seitdem v4.5.6 Cipi Rückstellungen Valkey statt redis-server. Es zeichnet sich durch Caching, Sitzungsspeicherung, Nachrichtenwarteschlangen und Echtzeit aus Rundfunk und Ratenbegrenzung.

Warum Valkey statt Redis

Valkey ist die wirklich open-source, BSD-lizenziert Gabel von Redis, verwaltet von der Linux Foundation. Es wurde im Jahr 2024 gegründet, nachdem Redis Inc. Redis weiterlizenziert hatte von der freizügigen BSD-Lizenz zur quellverfügbaren SSPL/RSALv2 – eine Änderung, die nicht mehr erfüllt wurde die open-source-Definition. Unterstützt von AWS, Google Cloud, Oracle und einer großen Community, Valkey setzt die gleiche kampferprobte Codebasis unter einer bleibenden Lizenz fort für immer kostenlos. Damit passt es perfekt zur MIT-Philosophie der No-Vendor-Lock-In-Philosophie von Cipi und wird ausgeliefert nativ im Universe-Repository von Ubuntu 24.04 (Pakete valkey-server + valkey-tools) – kein PPA eines Drittanbieters, dem man vertrauen kann.

Ebenso wichtig ist, dass Valkey ein ist drop-in replacement: es spricht genau das gleiche RESP Protokoll auf demselben Port (127.0.0.1:6379), ehrt dasselbe requirepass / bind Direktiven und liest das gleiche RDB/AOF-Datenformat. Ihr Apps brauchen Null Änderungen – die phpredis Erweiterung und Ihre bestehende REDIS_* .env Die Werte funktionieren weiterhin genau wie zuvor.

Wie Cipi es umsetzt

• Installieren — setup.sh installiert und konfiguriert Valkey (/etc/valkey/valkey.conf, Dienst valkey-server), gebunden an localhost nur zugänglich und mit einem Passwort geschützt.
• Service management — cipi service … verwaltet valkey-server(die Namenredis-server, redis, und valkey werden weiterhin als Aliase akzeptiert). Es wird zu den unbeaufsichtigten Upgrades hinzugefügt Blacklist, also verwaltet Cipi es anstelle eines automatischen Upgrades.
• Anmeldeinformationen – gespeichert unter valkey_user / valkey_password in /etc/cipi/server.json (das Erbe redis_* Schlüssel werden weiterhin als Fallback gelesen). Host: 127.0.0.1, Port: 6379.
• Passwort zurücksetzen — cipi reset valkey-password regeneriert die Passwort und startet den Dienst neu (cipi reset redis-password bleibt als Alias).

Migration von Redis (4.5.6 / 4.5.7)

Vorhandene Server werden automatisch auf Valkey umgeschaltet cipi self-update — keine App .env Bearbeitung erforderlich. Bei der Migration wird das aktuelle Redis-Passwort wiederverwendet (wiederhergestellt von server.json oder /etc/redis/redis.conf), erzwingt eine RDB SAVE und Schnappschüsse dump.rdb/AOF, purges redis-server, installiertvalkey-server + valkey-tools am gleichen Port mit dem gleichen requirepass / bind, stellt den Datensatz wieder her und schreibt ihn neu server.json (redis_* → valkey_*) und die unbeaufsichtigten Upgrades Blacklist – damit Cache, Sitzungen und in der Warteschlange befindliche Jobs den Wechsel überstehen.

v4.5.7 korrigiert den Paketnamen in valkey-server (der Ubuntu 24.04 Daemon-Paket; 4.5.6 zunächst verwendet valkey) und führt die Migration vollständig durch eigenständig und sicher. Es aktiviert automatisch die universe APT Komponente, wenn das Paket Wird nicht gefunden, führt eine Zustandsprüfung nach dem Start durch (PING → PONG mit dem Passwort) und rollt zurück zu redis-server — Wiederherstellung beider gespeicherter Daten Passwort und den Datensatz – wenn Valkey nicht installiert werden kann oder nicht fehlerfrei angezeigt wird. Der Datensatz Der Snapshot wird aufbewahrt, bis der Switch überprüft und dann bereinigt wird. Die Migration ist idempotent: Server bereits auf Valkey überspringe es.

Laravel Integration

Fügen Sie diese Variablen zu Ihrem hinzu .env über cipi app env myapp. Die Variablennamen bleibenREDIS_* – das ist es phpredis und Laravel redis Treiber erwarten, und Valkey Antworten auf der gleichen Buchse:

REDIS_HOST=127.0.0.1
REDIS_PASSWORD=Ihr-Passwort-vom-Server-json
REDIS_PORT=6379

Legen Sie dann die Treiber für jeden Anwendungsfall fest:

• Cache — CACHE_STORE=redis
• Sitzung — SESSION_DRIVER=redis
• Warteschlange — QUEUE_CONNECTION=redis (dann cipi worker restart myapp)
• Rundfunk — BROADCAST_CONNECTION=redis

Install the phpredis PHP Erweiterung für beste Leistung oder Nutzung predis/predis als reiner PHP-Fallback. Beide sprechen transparent mit Valkey.

Selbstaktualisierung

Cipi kann sich von GitHub selbst aktualisieren, ohne Auswirkungen auf eine App, Datenbank oder Konfiguration.

$ cipi self-update --check   # check for a new version
$ cipi self-update           # update to latest

Update-Prozess

1. Lädt die neueste Version von GitHub herunter
2. Sichert die aktuelle Installation auf /opt/cipi.bak.YYYYMMDDHHMMSS/
3. Ersetzt CLI- und lib-Skripte
4. Führt alle ausstehenden Schritte aus Migrationsskripte in der Reihenfolge (z. B. neue Nginx-Richtlinien, neue Pakete)
5. Aktualisiert die Versionsdatei

Migrationsskripte leben in lib/migrations/ und sind nach Version benannt (z.B.4.1.0.sh, 5.0.18.sh). Beim Update von v4.0.0 auf v4.2.0 wird Cipi automatisch ausgeführt4.1.0.sh und 4.2.0.sh in Ordnung. Ihre Apps, Datenbanken und Konfigurationen werden nie berührt.

Aktuelle Migrationen verbessern die Zuverlässigkeit, ohne App-Daten zu ändern: 5.0.6 – Standard-IP-Whitelist-Datei und neu generierte API Sudoer;5.0.9 — cipi php switch in sudoers für PUT /api/php/default; 5.0.13 — Nach dem Update API/GUI Eigentum zurückfordern; 5.0.14–5.0.17 — zeitgesteuerte GitHub/Packagist-Panel-Paketaktualisierungen (nicht mehr hängen bleiben). cipi self-update auf API/GUI Composer VCS-Klonen); 5.0.18 — Panel GUI nach Symlink reparieren/open_basedirHTTP 500 (cipi gui fix-permissions). Laufencipi self-update zu erreichen 5.1.0.

Migration 5.1.0

Die 5.1.0 Die Migration ist die größte der 5.x-Reihe. Auf einem vorhandenen Server:

• installiert den Wrapper für die automatische Bereitstellung und verweist die webhook cron jeder App darauf;
• backfills the CLI 99-cipi.ini und schreibt FPM-Pools neu, sodass sie das erben serverweite Datei – siehe cipi ini;
• wandelt den fest codierten nächtlichen Sicherungsauftrag in einen um default Backup-Profil, Übernahme des Bestehenden --weeks Aufbewahrung;
• übernimmt den Backup-Zeitplan mit dem verwalteten Crontab-Block;
• behauptet das :443 Standardserver wenn nichts anderes tut.

Jeder Schritt degradiert zur Warnung und geht weiter. Das ist wichtig: Auf einem frühen 5.1.0-Build a grep das mit nichts übereinstimmte, konnte die Migration unter scheitern lassen set -o pipefail, und eine fehlgeschlagene Migration macht cipi self-update Verweigern Sie die Freigabe und versuchen Sie es erneut, was fehlschlägt wieder, jede Nacht.

Wenn das Update selbst fehlschlägt

Up to 5.0.x, cipi self-update meldete nur „Download fehlgeschlagen“ – git's stderr war verworfen, also die eine Nachricht, die erklärt, was passiert ist (kein DNS, kein ausgehender HTTPS, ein fehlender ein Zweig, eine volle Festplatte, ein abgelaufenes CA-Bundle) hat niemanden erreicht. Seitdem v5.1.0 die Der tatsächliche Fehler wird ausgedruckt, die wahrscheinliche Ursache wird benannt und der Befehl zum manuellen Reproduzieren wird angezeigt. Der Klon läuft auch mit einer Zeitüberschreitung von 180 Sekunden, anstatt auf unbestimmte Zeit hängen zu können, und a fehlt git wird als solches gemeldet. Ein unbeaufsichtigtes nächtliches Update sendet jetzt auch das self_update Benachrichtigung, so dass es nicht mehr wortlos landet.

Zum Beispiel die 4.5.5 Migration rüstet vorhandene Apps mit den neuen nach ll='ls -al' Shell-Alias: Der Alias wird an jede App angehängt ~/.bashrc einmal (nur wenn es fehlt, der Besitz bleibt erhalten), sodass Apps, die vor 4.5.5 erstellt wurden, es beim nächsten Mal erhalten cipi self-update.

Automatische Wartungs-Crons

Cipi plant während der Installation mehrere Jobs auf Root-Ebene. Crontabs auf App-Ebene (Scheduler, Deploy). Auslöser) sind getrennt – siehe Benutzer-Crontab.

Wildcard-Domains

Cipi tut es nichtunterstützt Wildcard-Domänen (*.myapp.com) nativ. Die Block ist zweifach und architektonisch – kein Konfigurationsdetail.

Warum Platzhalter nicht unterstützt werden

1 – Domänenvalidierung wird abgelehnt *
Jede Domain, an die übergeben wurde cipi alias add (und cipi app create) wird validiert gegen einen strengen regulären Ausdruck, der erfordert, dass die Zeichenfolge beginnt [a-zA-Z0-9]. Das Sternchen schlägt sofort fehl, bevor nginx oder certbot jemals berührt werden.

2 – Certbot verwendet die Challenge HTTP-01, die keine Wildcard-Zertifikate ausstellen kann
cipi ssl install Anrufe certbot --nginx, das auf dem HTTP-01 (bzw TLS-ALPN-01) Herausforderung – Platzieren einer Verifizierungsdatei auf der Festplatte und Bereitstellung über Port 80. Lass uns Encrypt stellt nur Wildcard-Zertifikate über das aus DNS-01 Herausforderung, was erfordert Programmgesteuerter Zugriff auf den DNS-Anbieter Ihres DNS-Anbieters. Cipi lässt sich nicht mit irgendeinem DNS-Anbieter integrieren, also Selbst wenn die Validierung umgangen würde, würde Certbot die Ausstellung des Wildcard-Zertifikats verweigern.

Empfohlene Alternative – Multi-SAN-Zertifikat

Wenn Ihre Subdomains fest und aufzählbar sind (z. B. api, admin, www, staging), besteht der richtige Ansatz darin, jedes einzelne explizit hinzuzufügen Alias und lassen Sie Cipi ein einziges SAN-Zertifikat ausstellen, das alle abdeckt:

$ cipi alias add myapp api.myapp.com
$ cipi alias add myapp admin.myapp.com
$ cipi alias add myapp www.myapp.com
$ cipi ssl install myapp   # single cert, SAN covers all domains

Certbots --expand Das Flag (von Cipi intern verwendet) fügt die neuen SANs zu den vorhandenen hinzu Zertifikat ohne Ausstellung eines neuen Zertifikats. Die SAN-Liste hat für den typischen Gebrauch keine sinnvolle Grenze.

Manuelles Wildcard-Zertifikat (außerhalb Cipi)

Wenn Sie dynamische Subdomains benötigen (z. B. <tenant>.saas.com), können Sie einen Platzhalter erhalten Erstellen Sie das Zertifikat manuell mit einem DNS-Plugin für certbot und legen Sie es auf dem Server ab. Cipi wird nicht Verwalten, erneuern oder verfolgen Sie es – Sie besitzen den gesamten Lebenszyklus.

# example with the Cloudflare DNS plugin
$ pip install certbot-dns-cloudflare
$ certbot certonly --dns-cloudflare \
    --dns-cloudflare-credentials /root/.cloudflare.ini \
    -d "*.myapp.com" -d "myapp.com"

Nachdem Sie das Zertifikat erhalten haben, bearbeiten Sie den nginx vhost für die App direkt (/etc/nginx/sites-available/myapp), um auf die Wildcard-Zertifikatpfade zu verweisen und hinzuzufügen server_name *.myapp.com myapp.com;. Anschließend nginx neu laden:

$ nginx -t && systemctl reload nginx

Bearbeiten Sie die Nginx-Konfiguration

Um den Nginx Vhost für eine App anzupassen, bearbeiten Sie die Site-Konfiguration direkt. Nach Änderungen testen und Nginx nachladen.

$ sudo nano /etc/nginx/sites-available/<app>
$ sudo nginx -t && sudo systemctl reload nginx

Deinstallieren Sie Cipi

Cipi bietet keinen integrierten Deinstallationsbefehl. Wenn Sie Cipi vollständig aus a entfernen müssen Server, Befolgen Sie die nachstehenden Schritte in Ordnung. Dieses Verfahren entfernt alle Komponenten, die Cipi Installationen – Benutzer, Dienste, Pakete, Konfigurationen und Daten.

1 – Stoppen und entfernen Sie alle Apps

Entfernen Sie für jede von Cipi verwaltete App den Systembenutzer, das Home-Verzeichnis, die Datenbank, nginx vhost und PHP-FPM Pool, und supervisor Konfig.

# List all app users (members of cipi-apps group)
$ grep cipi-apps /etc/group

# For EACH app user, remove everything
$ supervisorctl stop <app_user>:*
$ rm -f /etc/supervisor/conf.d/<app_user>.conf
$ rm -f /etc/nginx/sites-enabled/<app_user>
$ rm -f /etc/nginx/sites-available/<app_user>
$ rm -f /etc/php/*/fpm/pool.d/<app_user>.conf
$ rm -f /etc/sudoers.d/cipi-<app_user>
$ mysql -e "DROP DATABASE IF EXISTS <app_user>; DROP USER IF EXISTS '<app_user>'@'localhost'; DROP USER IF EXISTS '<app_user>'@'127.0.0.1';"
$ userdel -r <app_user>

2 – Entfernen Sie die Cipi Benutzer und Gruppen

$ userdel -r cipi
$ groupdel cipi-ssh 2>/dev/null
$ groupdel cipi-apps 2>/dev/null

3 – Entfernen Sie Cipi Binärdateien, Bibliotheken und Daten

$ rm -f /usr/local/bin/cipi
$ rm -f /usr/local/bin/cipi-worker
$ rm -f /usr/local/bin/cipi-cron-notify
$ rm -f /usr/local/bin/cipi-auth-notify
$ rm -rf /opt/cipi
$ rm -rf /etc/cipi
$ rm -rf /var/log/cipi

4 — Entfernen Sie Cipi API (falls installiert)

$ systemctl stop cipi-queue 2>/dev/null
$ systemctl disable cipi-queue 2>/dev/null
$ rm -f /etc/systemd/system/cipi-queue.service
$ systemctl daemon-reload

5 – Entfernen Sie Cipi cron Jobs

# Edit root crontab and remove all Cipi entries
$ crontab -e
# Remove lines referencing: cipi self-update, certbot renewal, cache cleanup, RAM drop

6 – Entfernen Sie Cipi Konfigurationsdateien

# Sudoers
$ rm -f /etc/sudoers.d/cipi-sudo
$ rm -f /etc/sudoers.d/cipi-api

# Logrotate
$ rm -f /etc/logrotate.d/cipi-app-logs
$ rm -f /etc/logrotate.d/cipi-http-logs
$ rm -f /etc/logrotate.d/cipi-security-logs

# Unattended upgrades
$ rm -f /etc/apt/apt.conf.d/50cipi-unattended-upgrades
$ rm -f /etc/apt/apt.conf.d/20cipi-auto-upgrades

# System profile and MOTD
$ rm -f /etc/profile.d/cipi-env.sh
$ echo "" > /etc/motd

# MariaDB custom config
$ rm -f /etc/mysql/mariadb.conf.d/99-cipi.cnf

# PHP custom config (all versions)
$ rm -f /etc/php/*/fpm/conf.d/99-cipi.ini

# Nginx default page
$ rm -f /etc/nginx/sites-available/default
$ rm -f /etc/nginx/sites-enabled/default

7 – Installierte Pakete löschen

Entfernen Sie alle installierten Pakete. Überspringen Sie alle Pakete, die Sie für andere Zwecke behalten möchten.

$ systemctl stop nginx mariadb valkey-server fail2ban supervisor
$ systemctl stop php*-fpm

$ apt purge -y nginx* mariadb-server mariadb-client valkey-server \
    fail2ban supervisor certbot python3-certbot-nginx \
    php8.4* php8.5* nodejs

$ apt autoremove -y
$ apt autoclean

8 – Entfernen Sie APT Repositorys

$ add-apt-repository --remove ppa:ondrej/php -y
$ rm -f /etc/apt/sources.list.d/mariadb.list
$ rm -f /etc/apt/sources.list.d/nodesource.list
$ rm -f /etc/apt/keyrings/mariadb-keyring.pgp
$ apt update

9 – Entfernen Sie Composer und Deployer

$ rm -f /usr/local/bin/composer
$ rm -f /usr/local/bin/dep

10 – Auslagerungsdatei entfernen

$ swapoff /var/swap.1
$ rm -f /var/swap.1
# Remove the swap entry from /etc/fstab
$ sed -i '/swap\.1/d' /etc/fstab

11 – SSH- und PAM-Standardeinstellungen wiederherstellen

Cipi härtet SSH (deaktiviert Root-Anmeldung und Passwortauthentifizierung) und fügt PAM-Hooks hinzu. Wenn Sie eine Wiederherstellung benötigen Standardwerte:

# Restore sshd_config to allow password auth (if needed)
$ sed -i 's/^PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config
$ sed -i 's/^PermitRootLogin no/PermitRootLogin yes/' /etc/ssh/sshd_config

# Remove Cipi PAM hooks
$ sed -i '/cipi-auth-notify/d' /etc/pam.d/sshd
$ sed -i '/cipi-auth-notify/d' /etc/pam.d/sudo

# Restore sysctl
$ sed -i '/vm.swappiness/d' /etc/sysctl.conf
$ sysctl -p

$ systemctl restart sshd

12 — Reset firewall

$ ufw disable
$ ufw reset