Fortgeschritten

cipi api

Cipi kann optional eine REST-Ebene API auf dem Server aktivieren über cipi api <domain>. Es wird vom Paket Laravel unterstützt 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(Streambar HTTP)
• Server-Cockpit — PHP installieren/wechseln, SSH-Schlüssel, Dienste, SMTP, Gesundheitschecks, 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 App Cipi Agent Paket (cipi/agent auf jeder Laravel App).

Die cipi/api Paket

Auf einem normalen Cipi-Server installieren Sie das Paket nie manuell – cipi api <domain> Bestimmungen 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.jsonProjektion für nicht empfindliche Felder). Token-Fähigkeiten sind in definiert config/cipi.php – Listen Sie sie mit auf 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 das Eigentum an API/GUI 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 vhost API (einschließlich langsamer Anfragen, wenn konfiguriert). cipi api update aktualisiert das Panel-Paket API von Packagist (seitdem). 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-Verteilung 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 oder cipi self-update zur Reparatur vorhandener Paneele.

Seitdem v4.7.18 (Migrationen 4.7.15–4.7.18), Panel API Fehler auf Ubuntu 25.10+ / 26.04 sind Ende-zu-Ende behoben: sudo-rs lehnt ab 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.sh bricht 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 Vault/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 – App auflisten/zusammenführen .env Schlüssel (API 1.14.0+ / Cipi 5.0.3+)
• apps-auth – gemeinsames 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 (API1.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 – Integritätsprüfungen pro App festlegen, deaktivieren und ausführen (API 1.15.0+)
• ip-whitelist-view – Panel API / MCP IP-Zulassungsliste lesen (API 1.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 — Datenbanken erstellen
• 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-Paket API (gleiche Einträge wie php artisan cipi:token-abilities auf dem Server). Migration 4.6.3rü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 Accepted mit einem job_id abfragen über 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 akzeptiert optional custom (boolean) und docroot (String-)Parameter zum Erstellen benutzerdefinierte 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 mit 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. Behalten Sie 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 (einschließlich HTTPS) 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}. Für diese Endpunkte ist API erforderlich. 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 Der 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 409wenn 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 Paket API 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+ sie entlarven auch 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 unter /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 Werkzeug: 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 Filtert nach Engine (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); Unterstützung für mehrere Engines erforderlich Cipi 4.8+.

POST /api/apps/{name}/webhook/recreate erstellt den GitHub/GitLab neu und stellt webhook bereit; 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ähigkeit dbs-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": "…" }. RUHE: 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 den gleichen strukturierten JSON zurück wie cipi status (System, Ressourcen, Dienste, PHP Pools, App-Anzahl). Seit API 1.11.8+ der Endpunkt bevorzugt sudo cipi status auf 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 die Einheit systemd installiert ist (entspricht Cipi 4.8+). Erfordert die status-view Fähigkeit (API 1.11.6+). Der 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 (falls 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 API-Basis-URL und Ihr Token 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: application/json“

Serverstatus (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: application/json“

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

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

Senden "octane": "frankenphp" für den gleichen Effekt. Weglassen octane 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+; erfordert 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 „Inhaltstyp: application/json“ \
  -d '{"set":{"APP_DEBUG":"false"},"unset":["LEGACY_KEY"]}'

Artisan / App-Ausführung (asynchrone 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 „Inhaltstyp: application/json“ \
  -d '{"command":"cache:clear"}'

curl -sS -X POST „${CIPI_API_URL}/api/apps/myapp/run“ \
  -H „Autorisierung: Inhaber ${CIPI_API_TOKEN}“ \
  -H „Inhaltstyp: 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: application/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 als www-data und führt Cipi CLI Befehle aus sudo verwenden /etc/sudoers.d/cipi-api – eine explizite Whitelist von cipi Unterbefehle. Vault- und MariaDB-Anmeldeinformationen bleiben in Cipi, nicht in PHP.

• GET /api/dbs – läuft sudo cipi db list (synchronisieren). Erfordert Cipi 4.4.17+ (Migration fügt hinzu cipi db … zu Sudoers). Ohne es: sudo: a terminal is required. Liste mit mehreren Engines/Engines 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-api auf cipi 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 return HTTP 500 (siehe Fehlerbehebung oben).

IP-Whitelist (CLI)

Seit Cipi 5.0.6+, beschränken Sie die Panel-Clients API und MCP 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 aus public/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 + HTTPS erzwingen), Datenbanken (Motorenliste + optional engine auf Mutationen), Serverstatus, Jobabfrage mit strukturiert result Typen und MCP-Toolschemata. Aktuelle API-Paketversion: 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-access Fähigkeit ist ausreichend für alle 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.

• Anwendungen: AppList, AppShow, AppCreate (optional engine, octane), AppEdit, AppSuspend, AppUnsuspend, AppDelete, AppDeploy, AppDeployRollback, AppDeployUnlock, AppArtisan (Laravel Nur Apps; lehnt benutzerdefinierte Apps ab und tinker), 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+)
• Serververwaltung: 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 & Protokolle: JobShow (Status des asynchronen Jobs abfragen, analysiert result, und CLI Ausgabe), 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-Host API)
• Serverüberwachung: ServerStatus (strukturierter JSON-Abgleich GET /api/status / cipi status), ServiceList (Systemdienststatus über cipi service list)

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

Installieren des MCP-Servers

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

1. Konfigurieren Sie API mit cipi api <domain> und cipi api ssl
2. Erstellen Sie ein Token mit cipi api token create und wählen Sie mindestensmcp-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 stellt eine native Verbindung über HTTP her – keine Bridge erforderlich.

VS-Code

VS Code (mit GitHub Copilot) unterstützt MCP nativ seit 1.102. Hinzufügen zu .vscode/mcp.json oder laufen MCP: 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 Server MCP direkt aus 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 das mcp-remote Bridge zum Konvertieren von stdio in HTTP. 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 einmal mit 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 verbindet 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 – aktiviert die TLS-Überprüfung)
3. Erstellen Sie eine Hosting-Produkt mit diesem Server verknüpfen und konfigurieren Modul Einstellungen:

App-Typen

Bereitstellungslebenszyklus

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

Admin-Schaltflächen

In der WHMCS-Administratordienstansicht 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 von SSL fehlschlägt, ist dies bei der App der Fall weiterhin erfolgreich erstellt und es wird eine Warnung protokolliert.

Vollständiger API-Client

Das gebündelte CipiApiClient deckt die gesamte Cipi REST API Oberflä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 eine Registerkarte „Kundenbereich“, benutzerdefinierte Schaltflächen oder einen Live-Status von Cipi 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-Aufrufe 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 komplette 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

Archivverschlüsselung

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, .env Dateien, 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. Datenbankdaten– 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 existiert bereits – blockiert, es sei denn --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-Modus (--update)

Die Schlüsselfunktion für wiederholte Synchronisierung (z. B. Failover-Replikation). Ohne --update, Import weigert sich, bereits vorhandene Apps zu berühren. Mit --update, es Aktualisierungen vorhandene Apps und 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 .env ersetzt 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.
• Datenbankdaten — 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, erfolgt 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-Benutzerpasswort
• SSH-Bereitstellungsschlüssel (behalten vom ersten Import an)
• MariaDB Benutzeranmeldeinformationen (Ziel behält seine eigenen)
• SSL Zertifikate (run cipi ssl install separat)

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.0.18
  Exportiert 2026-03-06T15:00:00Z
  Quelle aws01 (3.120.xx.xx)
  Datenbank wahr
  Lagerung stimmt
 
  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 sichere wiederholte Ausführung über cron.

SSH-Setup für Push

Der Quellserver benötigt SSH-Zugriff auf das Ziel cipiBenutzer. 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.

Praktische Szenarien

Szenario 1: Alle Apps von AWS zu OVH migrieren

Sie haben 20 Apps auf AWS. Sie haben ein 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 (dieselben 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 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 Intervall cron (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 Zertifikate sind 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 – nein GitHub/GitLab Neukonfiguration benötigt.

Tresor und Verschlüsselung

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.

Architektur

Das System ist auf zwei Ebenen aufgebaut:

• Tresor — Transparente Verschlüsselung der 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 .json Erweiterung – 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 generiert eine 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

Wenn du rennst 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.

E-Mail-Benachrichtigungen

Cipi kann E-Mail-Benachrichtigungen senden, wenn Backup-Fehler, 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 standardmäßig aktiviert; Ereignisse werden immer protokolliert /var/log/cipi/events.log egal.

$ 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>:

Automatische Benachrichtigungen

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

• Sicherungsfehler (S3 Upload-Fehler, Dump-Fehler)
• Bereitstellungsfehler (Bereitstellungsfehler, Rollback-Trigger)
• System cron Jobfehler (ü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 – ausgelöst wann 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.log Fingerabdruckabgleich 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 umfasst den Server-Hostnamen, den App-Namen, die Domäne und die PHP-Version.

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.

Sicherheitsereignisprotokoll

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 Wrapper

Die cipi-cron-notify Das Dienstprogramm umschließt Systemjobs cron 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, den Cipi als Teil des Standardstapels installiert. Seitdem v4.5.6 Cipi Bestimmungen Valkey statt redis-server. Es zeichnet sich durch Caching, Sitzungsspeicherung, Nachrichtenwarteschlangen und Echtzeit aus Rundfunk und Ratenbegrenzung.

Warum Valkey statt Redis

Valkey ist das wirklich open-source, BSD-lizenziert Fork von Redis, verwaltet von der Linux Foundation. Es wurde im Jahr 2024 erstellt, nachdem Redis Inc. Redis erneut lizenziert 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 fortfür immer kostenlos. Dadurch passt es perfekt zur MIT-Philosophie von Cipi, der No-Vendor-Lock-In-Philosophie, und es 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 Drop-in-Ersatz: 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 implementiert

• 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.
• Servicemanagement — cipi service … verwaltet valkey-server (die Namen redis-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, installiert valkey-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 dieuniverse 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 der Datensatz – wenn Valkey nicht installiert werden kann oder nicht ordnungsgemäß funktioniert. Der Datensatz Der Snapshot wird aufbewahrt, bis der Switch überprüft und dann bereinigt wird. Die Migration ist idempotent: Server bereits am Valkey überspringen.

Laravel-Integration

Fügen Sie diese Variablen zu Ihrem hinzu .env über cipi app env myapp. Die Variablennamen bleiben REDIS_* – das ist es phpredis und Laravels redis Treiber erwarten, und Valkey antwortet auf demselben Socket:

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

Installieren Sie die phpredis PHP-Erweiterung für beste Leistung oder Verwendung predis/predis als reiner PHP-Fallback. Beide sprechen transparent mit Valkey.

Selbstaktualisierung

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

$ 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-Direktiven, new 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ührt 4.1.0.sh und 4.2.0.sh in Ordnung. Ihre Apps, Datenbanken und Konfigurationen werden nie berührt.

Neu 5.0.x 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 der Aktualisierung den Besitz von API/GUI 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-Klone);5.0.18 — Panel GUI nach Symlink/ reparierenopen_basedir HTTP 500 (cipi gui fix-permissions). Lauf cipi self-update zu erreichen 5.0.18.

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 nicht unterstü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 Herausforderung HTTP-01, die keine Wildcard-Zertifikate ausstellen kann
cipi ssl install Anrufe certbot --nginx, das auf HTTP-01 (oder 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 API Ihres DNS-Anbieters. Cipi lässt sich daher nicht in einen DNS-Anbieter integrieren 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 Flag (intern von Cipi verwendet) fügt die neuen SANs zu den vorhandenen hinzu Zertifikat ohne Ausstellung eines neuen Zertifikats. Die SAN-Liste weist für den typischen Gebrauch keine sinnvolle Begrenzung auf.

Manuelles Wildcard-Zertifikat (außerhalb von 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 – der Lebenszyklus liegt vollständig in Ihrer Hand.

# 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 vhost nginx 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;. Dann 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 neu laden.

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

Cipi deinstallieren

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, den vhost nginx und PHP-FPM Pool, und supervisor config.

# 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 den Benutzer und die Gruppen Cipi

$ 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 die Konfigurationsdateien Cipi

# 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 Pakete, die Cipi installiert haben. Ü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 – Firewall zurücksetzen

$ ufw disable
$ ufw reset