Infrastruktur

cipi php

PHP 8.5 wird beim Setup vorinstalliert. Weitere Versionen können jederzeit hinzugefügt werden; seitdem v4.5.12 Cipi prüft APT Quellen pro Ubuntu Codename – normalerweise die ondrej/php PPA am 24.04, Pakete.sury.org am 26.04, wenn Launchpad keine Suite hat, oder Ubuntu main als letzter Ausweg (koinstallierbar 8.3–8.5, sofern das ausgewählte Repo dies unterstützt).

$ cipi php list              # list installed versions, status, and system default
$ cipi php install 8.4       # install an additional PHP version (8.3–8.5)
$ cipi php switch 8.4        # set system default (root/cipi, API pool)
$ cipi php remove 8.1        # remove a version, incl. legacy (blocks if default or apps use it)
$ cipi php upgrade           # apply security patches to all installed PHP packages

Sicherheitspatch-Upgrades

Seitdem v4.7.13, PHP Pakete sind davon ausgeschlossen unattended-upgrades und stattdessen von Cipi verwaltet. cipi php upgrade läuft apt-get update und --only-upgrade auf jedem installiert php* und libphp* Paket und startet dann die betroffenen PHP-FPM-Pools neu. Wenn SMTP konfiguriert ist und Pakete wurden aktualisiert, Cipi sendet eine E-Mail (php_upgrade auslösen; deaktivieren mit cipi notifications disable php_upgrade).

Eine wöchentliche Prüfung läuft automatisch ab Sonntag um 03:30 Uhr über Root Crontab (umschlossen von cipi-cron-notify). Protokoll: /var/log/cipi/php-upgrade.log. Bestehende Server erhalten den cron cipi self-update (Migration 4.7.13).

Systemstandard vs. App-spezifisch PHP

Die Systemstandard ist die PHP-Version, die von verwendet wird root und cipi Benutzer, der FPM-Pool Cipi API und der Warteschlangenarbeiter API. Benutzen cipi php switch <ver> zu ändere es. Der Befehl migriert den API-Pool (und den GUI FPM-Pool, sofern installiert) und erstellt ihn neu Panel-Sockets und startet den API-Worker neu. Seitdem 5.0.9+, PUT /api/php/default umschließt dies über das Panel API (php-manage Fähigkeit). Seitdem 5.0.10–5.0.12, Schalter toleriert teilweise update-alternatives Bei Erfolg werden schreibgeschützte Roots bei Bedarf erneut bereitgestellt und API/GUI beibehalten. FPM-Pools auf der Zielversion, um nginx 502 zu vermeiden.

RUHE: GET /api/php, POST /api/php/install, DELETE /api/php/{version}, PUT /api/php/default (API 1.15.0+ / Cipi 5.0.6+). CLI JSON: cipi php list --json (seit 5.0.6).

Jede App hat ihre eigene besitzen PHP Version (eingestellt auf app create oder über cipi app edit --php=). Deployer, Composer, Crontab-Bereitstellungstrigger und cipi sync import Wird immer mit dem konfigurierten PHP der App ausgeführt – niemals mit dem Systemstandard.

Um eine vorhandene App auf eine andere Version umzustellen:

$ cipi app edit myapp --php=8.5

Dadurch wird die Version PHP ohne Ausfallzeit im laufenden Betrieb ausgetauscht: Der FPM-Pool, der Nginx-Socket und Supervisor werden aktualisiert. Worker, Crontab, Deployer-Konfiguration und .env in einer atomaren Operation.

cipi db

Cipi erstellt für jeden eine eigene Datenbank Laravel App automatisch während app create. MariaDB (Hafen 3306) ist die native Standardeinstellung; seitdem v4.8.0 Sie können es auch optional installieren PostgreSQL (Hafen 5432) und wählen Sie eine Engine pro Datenbank oder App aus. Benutzerdefinierte Apps erhalten keine Datenbank – verwenden cipi db create --name=<app> wenn Sie eines benötigen (z. B. für WordPress oder ein anderes). CMS). Nach der Einrichtung wird eine gebrauchsfertige Verbindungs-URL angezeigt (MariaDB:mariadb+ssh://), kombiniert SSH-Anmeldeinformationen, Server-IP und Datenbankinformationen für GUI Clients wie TablePlus, DBeaver oder Sequel Pro.

Motoren (v4.8.0+)

$ cipi db install pgsql              # install optional PostgreSQL
$ cipi db uninstall pgsql|mariadb    # remove a non-default engine (destroys data)
$ cipi db default mariadb|pgsql      # server-wide default when --engine is omitted
$ cipi db engines                    # installed engines, ports, and default

Datenbanklebenszyklus

$ cipi db create                              # interactive
$ cipi db create --name=analytics             # non-interactive (default engine)
$ cipi db create --name=analytics --engine=pgsql
$ cipi db list [--engine=mariadb|pgsql]       # list databases with sizes
$ cipi db backup myapp [--engine=…]
$ cipi db restore myapp backup.sql.gz [--engine=…]
$ cipi db password myapp [--engine=…]         # regenerate password
$ cipi db delete analytics [--engine=…]

Laravel Apps speichern die ausgewählte Engine in App-Metadaten; Sichern, synchronisieren und cipi app reset-db-password Folge ihm. Benutzen cipi app create --engine=pgsql (oder die interaktive Eingabeaufforderung), um eine Laravel-App bereitzustellen auf PostgreSQL — .env und die Verbindungs-URL stimmen mit der Engine überein. Zurücksetzen des Root-Passworts: cipi reset db-password [--engine=].

cipi alias

Fügen Sie jeder App mehrere Domänen oder Subdomänen hinzu. Führen Sie nach dem Hinzufügen von Aliasen Folgendes aus: cipi ssl install das Zertifikat mit SAN-Abdeckung für alle bereitzustellen oder zu erneuern Domänen. Seitdemv4.8.0, cipi alias add|remove regeneriert den vhost und wendet SSL erneut an certbot install --redirect daher wird HTTPS nicht gelöscht.

$ cipi alias add myapp www.myapp.com
$ cipi alias add myapp myapp.it
$ cipi alias list myapp
$ cipi alias remove myapp myapp.it

Für kanonische Weiterleitungen www ↔ Apex bevorzugen Sie cipi www anstatt den Gegenhost manuell zu verwalten.

cipi www

Seitdem verfügbar v4.8.0. Verwalten Sie www/apex-Aliase und kanonische 301-Weiterleitungen für eine App. Staat lebt in apps.json (www_redirect); Nginx gibt ein dediziertes aus Umleitungsserverblock (ACME-Pfad bleibt öffentlich), der die vhost-Neugenerierung übersteht. SSL wird erneut angewendet über certbot install --redirect.

$ cipi www add myapp              # add counterpart host (www ↔ apex)
$ cipi www force-to-root myapp    # 301 www.domain → domain
$ cipi www force-from-root myapp  # 301 domain → www.domain
$ cipi www clear myapp            # clear redirect state
$ cipi www status myapp           # inspect redirect state

force-to-root / force-from-root Fügen Sie den fehlenden Alias ​​bei Bedarf automatisch hinzu.

cipi domains

Seitdem verfügbar v4.5.5. Ein Befehl der obersten Ebene, der auflistet jeder Domain und Alias übergreifend alle Apps in einer einzigen Tabelle – das globale Gegenstück zu die Pro-App cipi alias list <app>. Ideal für die Prüfung des Ganzen Domain-zu-App-Mapping oder Erkennen einer Domain, der noch ein Zertifikat fehlt.

$ cipi domains   # list all domains and aliases across every app

Jede Zeile zeigt die folgenden Spalten:

In einer Fußzeile werden die Gesamtzahlen (Anzahl der Domänen, Apps, Zertifikate und gesperrten Apps) zusammengefasst Es ist einfach, die gesamte Zuordnung auf einen Blick zu überprüfen.

cipi ssl

Certbot verwaltet Let's Encrypt Zertifikate. Zertifikate erneuern sich automatisch über einen wöchentlichen cron. cipi ssl status Zeigt Ablaufdaten mit farbcodierten Warnhinweisen an: grün (>30 Tage), gelb (14–30 Tage), rot (<14 Tage).

$ cipi ssl install myapp   # provision / renew — includes all aliases (SAN)
$ cipi ssl force myapp     # re-apply HTTP→HTTPS redirect (no new issuance)
$ cipi ssl renew            # force renewal of all certificates
$ cipi ssl status           # show all certs with expiry dates

# DNS-01 via Cloudflare (v5.0+) — wildcard certs
$ cipi ssl dns set --provider=cloudflare --token=YOUR_CF_TOKEN
$ cipi ssl install myapp --dns=cloudflare
$ cipi ssl install myapp --dns=cloudflare --wildcard

Seitdem v4.8.0, cipi ssl force <app> wendet HTTP → HTTPS erneut an Weiterleitung für eine App, die bereits über ein Let's Encrypt-Zertifikat verfügt – ohne ein neues auszustellen. cipi ssl install setzt auch force_https in apps.json automatisch.

Seitdem v5.0, optional DNS-01 Herausforderungen über Cloudflare ersetzen die Standardfluss HTTP-01, wenn Sie Platzhalterzertifikate benötigen oder Port 80 nicht verfügbar machen können. Einmal konfigurieren mit cipi ssl dns set, dann pass --dns=cloudflare (und optional --wildcard) zu cipi ssl install.

cipi backup

Sichern Sie Datenbanken und Speicher auf Amazon S3 oder einem beliebigen S3-kompatiblen Anbieter (Hetzner Object Storage, DigitalOcean Spaces, Backblaze B2, MinIO usw.).

Einrichtung

$ cipi backup configure
# → AWS Access Key ID
# → AWS Secret Access Key
# → Bucket name
# → Region
# → Endpoint URL (leave empty for AWS; required for other providers)

S3-kompatible Endpunkte

Backups ausführen

$ cipi backup configure              # configure S3 credentials
$ cipi backup run                    # backup all apps
$ cipi backup run myapp              # backup a single app
$ cipi backup list                   # list all backups
$ cipi backup list myapp             # list backups for one app
$ cipi backup prune myapp --weeks=4  # delete backups older than 4 weeks

Jedes Backup wird hochgeladen s3://your-bucket/cipi/appname/YYYY-MM-DD_HHMMSS/ und enthält:

• db.sql.gz — komprimierter Datenbank-Dump
• shared.tar.gz – das Ganze shared/ Verzeichnis (.env + storage/)

Seitdem v4.7.14, Backup-Staging ist standardmäßig auf /var/tmp (Festplatte) statt /tmp (häufig ein kleines RAM-gestütztes tmpfs), sodass große Apps nicht mehr während der Sicherung ausfallen, wenn tmpfs füllt sich. Überschreiben mit tmpdir in backup.json (eingestellt über cipi backup configure) oder die CIPI_BACKUP_TMPDIR Umgebungsvariable.

Automatische Backups planen

# Add to root crontab (crontab -e)
0 2 * * * /usr/local/bin/cipi backup run >> /var/log/cipi/backup.log 2>&1

Alte Backups aus S3 bereinigen

Mit der Zeit sammeln sich Backups an. Benutzen cipi backup prune um Sicherungsordner zu löschen, die älter sind als N Wochen von S3. Führen Sie es als cron-Job neben der Sicherung selbst aus.

$ cipi backup prune myapp --weeks=4   # delete backups older than 4 weeks
$ cipi backup prune myapp --weeks=2   # keep only the last 2 weeks

Fügen Sie beide Befehle zur Root-Crontab hinzu, damit sie automatisch ausgeführt werden:

# root crontab — backup at 02:00, prune at 03:00 (keep 4 weeks)
0 2 * * * /usr/local/bin/cipi backup run myapp >> /var/log/cipi/backup.log 2>&1
0 3 * * * /usr/local/bin/cipi backup prune myapp --weeks=4 >> /var/log/cipi/backup-prune.log 2>&1

Benutzer-Crontab

Cipi fügt automatisch einen Crontab-Eintrag für den Laravel-Planer hinzu, wenn eine App erstellt wird:

# installed automatically by cipi app create
* * * * * /usr/bin/php8.5 /home/myapp/current/artisan schedule:run >> /dev/null 2>&1

Dieser Eintrag läuft als myapp Linux-Benutzer jede Minute unter Verwendung der ausgewählten Version PHP die App. Es wird automatisch aktualisiert, wenn Sie die Version von PHP über ändern cipi app edit myapp --php=X.

Anzeigen der aktuellen Crontab

# as root — view the app user's crontab
$ crontab -u myapp -l

# or after switching to the app user
$ su - myapp
myapp@server:~$ crontab -l

Hinzufügen benutzerdefinierter cron-Jobs

Sie können der Crontab des App-Benutzers zusätzliche cron-Jobs hinzufügen. Wechseln Sie zuerst zum App-Benutzer, um Jobs sicherzustellen Mit dem richtigen Benutzerkontext und den richtigen Dateiberechtigungen ausführen:

$ su - myapp
myapp@server:~$ crontab -e

Beispieleinträge, die Sie hinzufügen könnten:

# existing Laravel scheduler (do not remove)
* * * * * /usr/bin/php8.5 /home/myapp/current/artisan schedule:run >> /dev/null 2>&1

# nightly database backup at 2 AM
0 2 * * * /usr/local/bin/cipi db backup myapp >> /home/myapp/logs/backup.log 2>&1

# custom script every 15 minutes
*/15 * * * * /home/myapp/current/scripts/sync.sh >> /home/myapp/logs/sync.log 2>&1

Überprüfen, ob cron funktioniert

# check system cron log
$ grep CRON /var/log/syslog | grep myapp | tail -20

# check Laravel scheduler execution
$ cipi app artisan myapp schedule:list

cipi schedule

Seitdem v5.0, verwalten Sie den Laravel Scheduler-Crontab-Eintrag, der ausgeführt wird schedule:run (Die Crontab selbst existierte bereits; sie ist jetzt umschaltbar und kann nachverfolgt werden apps.json).

$ cipi schedule on myapp
$ cipi schedule off myapp
$ cipi schedule status myapp

cipi worker & Laravel Horizon

Jede App erhält einen Standard-Supervisor-Worker für default Warteschlange. Sie können weitere hinzufügen Warteschlangen mit benutzerdefinierten Prozesszahlen und Zeitüberschreitungen.

$ cipi worker add myapp --queue=emails --processes=3
$ cipi worker add myapp --queue=exports --processes=1 --timeout=7200
$ cipi worker list myapp
$ cipi worker edit myapp --queue=default --processes=3
$ cipi worker remove myapp emails
$ cipi worker restart myapp   # restart all workers for the app
$ cipi worker stop myapp      # stop all workers for the app (used during deploys)

# Laravel Horizon (v5.0+) — mutually exclusive with queue:work workers
$ cipi worker horizon enable myapp
$ cipi worker horizon status myapp
$ cipi worker horizon disable myapp

Mit Horizon aktiviert, die Bereitstellung wird ausgeführt horizon:terminate und startet neu Arbeiter über cipi-worker. Sie können nicht klassisch laufen queue:work Arbeiter und Horizon gleichzeitig in derselben App.

Worker werden vor dem Symlink-Austausch gestoppt und nach jedem Deployment neu gestartet, um dies zu verhindern Supervisor von der Abholung veraltet artisan Wege. Supervisor ist mit konfiguriert autorestart=unexpected Daher werden Worker nur bei unerwarteten Exits neu gestartet, nicht bei ordnungsgemäßen Exits stoppt.

App-Benutzerhelfer: cipi-worker

Jeder App-Benutzer kann Worker ohne Root neu starten, stoppen oder überprüfen – über einen eingeschränkten sudo-Helper installiert bei /usr/local/bin/cipi-worker:

# run as the app user (SSH or sudo su - myapp)
$ sudo cipi-worker status myapp
$ sudo cipi-worker stop myapp      # used by Deployer before symlink swap
$ sudo cipi-worker restart myapp

Als Root verwenden cipi worker list|restart|stop <app> stattdessen. Es gibt keine cipi worker status Admin-Befehl – verwenden cipi worker list oder der App-Benutzer Helfer oben.

cipi health

Seitdem v5.0, konfigurieren Sie HTTP Integritätsprüfungen pro App. Ein cron wird alle 5 Minuten ausgeführt. danach 3 aufeinanderfolgende Fehler Cipi benachrichtigt über health_fail Trigger (SMTP wann konfiguriert).

$ cipi health set myapp --url=https://myapp.com/up --expect=200
$ cipi health check myapp
$ cipi health list
$ cipi health unset myapp

# Structured output (v5.0.6+) — panel API / scripts
$ cipi health list --json
$ cipi health check myapp --json

RUHE: GET /api/health, GET|PUT|DELETE /api/apps/{name}/health, POST /api/apps/{name}/health/check (API 1.15.0+ / Cipi 5.0.6+).

cipi firewall

Cipi installiert UFW mit standardmäßig geöffneten Ports 22, 80 und 443. Verwenden Sie zur Verwaltung die Firewall-Befehle zusätzliche Regeln, ohne UFW direkt zu berühren.

$ cipi firewall allow 3306                  # open a port
$ cipi firewall allow 3306 --from=10.0.0.5  # allow from specific IP
$ cipi firewall allow 3306 --from=10.0.0.0/24 # allow from subnet
$ cipi firewall deny 8080                   # block a port
$ cipi firewall list                        # show all rules

cipi ban

Überprüfen und verwalten Sie Fail2ban-Verbote direkt aus dem CLI. Cipi konfiguriert Fail2ban mit Progressive Sperre: eine 24-Stunden-Grundsperre, die sich bei jedem wiederholten Vergehen verdoppelt, bis zu einer Höchstdauer von 7 Tagen, mit maximaler Wiederholungsversuche auf 3 reduziert. Ein dedizierter recidive Nach drei Sperren werden Wiederholungstäter für sieben Tage ins Gefängnis gesperrt innerhalb von 24 Stunden.

$ cipi ban list                        # list all banned IPs, grouped by jail
$ cipi ban unban 203.0.113.42           # unban a specific IP from all jails

cipi ban list

Listet alle derzeit von Fail2ban gesperrten IP-Adressen auf, gruppiert nach Gefängnis (z. B. sshd, recidive). Nützlich für eine schnelle Sicherheitsüberprüfung oder vor der Durchführung einer Aufhebung des Banns.

cipi ban unban <IP>

Entfernt die angegebene IP von alle Fail2ban-Gefängnisse auf einmal. Praktisch, wenn Sie ein legitimer Benutzer sind oder der CI-Läufer wird versehentlich ausgesperrt.

cipi service

Überprüfen und steuern Sie die Systemdienste, die Cipi direkt vom CLI aus versorgen. Nginx verwendet eine anmutige Neuladen (keine Ausfallzeit) anstelle eines vollständigen Neustarts.

$ cipi service list                    # status of all services
$ cipi service list nginx              # status of a specific service
$ cipi service restart                 # restart all services
$ cipi service restart nginx           # graceful reload (zero downtime)
$ cipi service restart php             # restart all PHP-FPM versions
$ cipi service start fail2ban
$ cipi service stop supervisor         # asks for confirmation

# Structured output (v5.0.6+) — panel API
$ cipi service list --json

RUHE: GET /api/services, POST /api/services/{name}/restart (API 1.15.0+ / Cipi 5.0.6+; Fähigkeiten services-view / services-manage).

Unterstützte Dienstnamen: nginx, mariadb, postgresql (Aliasnamen: pgsql, postgres — bei Installation über cipi db install pgsql), valkey-server, supervisor, fail2ban, php<ver>-fpm (z.B. php8.5-fpm). Das Schlüsselwort php zielt auf alle installierten PHP-FPM-Versionen gleichzeitig ab. Für das Cache-Backend: redis-server, redis, und valkey werden als Aliase von akzeptiert valkey-server.

Valkey – der BSD-lizenzierte, Redis-kompatible Fork – ist im Standard-Stack enthalten und ersetzt ihn redis-server seit Cipi 4.5.6. Es wird mit einem Passwort installiert, an das gebunden ist localhost nur und seine Anmeldeinformationen (Benutzer, Passwort) werden darin gespeichert /etc/cipi/server.json und am Ende der Installation angezeigt. valkey-server wird zur Blacklist für unbeaufsichtigte Upgrades hinzugefügt – Cipi verwaltet es, also ist es nicht automatisch aktualisiert. Siehe die Valkey Weitere Informationen finden Sie im Abschnitt und die automatische Redis → Valkey Migration.

cipi ssh – SSH-Schlüsselverwaltung

Verwalten Sie die autorisierten SSH-Schlüssel für cipi user – der Administrator-SSH-Einstiegspunkt. Die cipi Benutzer (Gruppe cipi-ssh) verwendet nur den öffentlichen Schlüssel; Root-Login ist deaktiviert. App-Benutzer (Gruppe cipi-apps) Mit Passwort verbinden – siehe SSH als der App-Benutzer.

Befehle

$ cipi ssh list                 # list all authorized keys with fingerprint, comment, and current-session marker
$ cipi ssh add [key]             # add a new SSH public key (validates format, prevents duplicates)
$ cipi ssh remove [n]            # remove a key by number
$ cipi ssh rename [n] [name]     # change the display name / comment of a key

# Structured output (v5.0.6+) — panel API
$ cipi ssh list --json

RUHE: GET|POST /api/ssh/keys, DELETE /api/ssh/keys/{n} (API 1.15.0+ / Cipi 5.0.6+).

Sicherheitsmechanismen

cipi ssh remove enthält zwei Sicherheitsmaßnahmen zur Verhinderung einer Aussperrung:

• Schutz der aktuellen Sitzung – Sie können den von Ihrem aktiven SSH verwendeten Schlüssel nicht entfernen Sitzung.
• Schutz des letzten Schlüssels — Sie können den letzten verbleibenden autorisierten Schlüssel nicht entfernen.

Wichtige Kommentare

SSH-Schlüssel werden mit intakten Originalkommentaren gespeichert, sodass sich die einzelnen Schlüssel leicht identifizieren lassen gehört dazu. Benutzen cipi ssh rename So ändern Sie den Anzeigenamen einer beliebigen Taste:

# list keys to find the number
$ cipi ssh list

# rename key #2
$ cipi ssh rename 2 "john-macbook"

E-Mail-Benachrichtigungen

Wenn SMTP konfiguriert ist, sendet Cipi jedes Mal eine E-Mail-Benachrichtigung, wenn ein Schlüssel hinzugefügt, entfernt oder umbenannt wird. Die Benachrichtigung umfasst den Server-Hostnamen, die IP-Adresse, den Schlüsselfingerabdruck, den Schlüsselkommentar, den Zeitstempel, und verbleibende Schlüsselanzahl. Umbenennungsbenachrichtigungen enthalten auch den alten und neuen Schlüsselnamen.

cipi – Server- und Selbstaktualisierung

Befehle der obersten Ebene für den Serverstatus und die Cipi-Selbstverwaltung.

$ cipi status              # CPU, RAM, disk, services, PHP versions, apps
$ cipi version             # show installed Cipi version
$ cipi self-update         # update Cipi to the latest version
$ cipi self-update --check # check for updates without installing

Zurücksetzen von Passwort und Anmeldeinformationen

Cipi bietet Befehle zum Neugenerieren von Passwörtern auf Serverebene. Neue Passwörter werden in gespeichert /etc/cipi/server.json (über Vault verschlüsselt) und auf dem Bildschirm angezeigt. Speichern Sie sie sofort — Sie werden nur einmal angezeigt.

$ cipi reset root-password              # regenerate the root Linux user SSH password
$ cipi reset db-password [--engine=…]   # regenerate root password (default or chosen engine)
$ cipi reset valkey-password           # regenerate the Valkey password and restart the service