Infraestructura

cipi php

PHP 8.5 está preinstalado durante la instalación. Se pueden agregar versiones adicionales en cualquier momento; desde v4.5.12 Cipi sondea APT fuentes por Ubuntu nombre en clave (generalmente el ondrej/php PPA el 24.04, paquetes.sury.orgel 26.04 cuando Launchpad no tiene suite, o Ubuntu main como último recurso (coinstalable 8.3–8.5 donde el repositorio elegido lo admita).

$ 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

Actualizaciones de parches de seguridad

desde v4.7.13, PHP paquetes están excluidos de unattended-upgrades y gestionado por Cipi en su lugar. cipi php upgrade corre apt-get update y --only-upgrade en cada instalado php* y libphp* paquete, luego reinicia los grupos de PHP-FPM afectados. Cuando SMTP está configurado y Los paquetes se actualizaron, Cipi envía un correo electrónico (php_upgrade desencadenante; desactivar con cipi notifications disable php_upgrade).

Un control semanal se ejecuta automáticamente en Domingo a las 03:30 a través del crontab raíz (envuelto por cipi-cron-notify). Registro: /var/log/cipi/php-upgrade.log. Los servidores existentes reciben el cron en cipi self-update (migración 4.7.13).

Valor predeterminado del sistema versus específico de la aplicación PHP

el valor predeterminado del sistema es la versión PHP utilizada por el root y cipiusuarios, el grupo Cipi API FPM y el trabajador de cola API. uso cipi php switch <ver> a cambiarlo. El comando migra el grupo API (y el grupo GUI FPM cuando está instalado), recrea tomas del panel y reinicia el trabajador API. desde 5.0.9+, PUT /api/php/default envuelve esto a través del panel API (php-manage capacidad). desde 5.0.10–5.0.12, el interruptor tolera parcial update-alternatives éxito, vuelve a montar las raíces de solo lectura cuando es necesario y mantiene API/GUI FPM se agrupa en la versión de destino para evitar nginx 502.

DESCANSO: 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 (desde 5.0.6).

Cada aplicación tiene su propio Versión PHP (establecida en app create o vía cipi app edit --php=). Implementador, Composer, activadores de implementación de crontab y cipi sync import Ejecútelo siempre con el valor PHP configurado de la aplicación, nunca con el valor predeterminado del sistema.

Para cambiar una aplicación existente a una versión diferente:

$ cipi app edit myapp --php=8.5

Esto intercambia en caliente la versión PHP sin tiempo de inactividad: actualiza el grupo de FPM, el socket Nginx, Supervisor. trabajadores, crontab, configuración del implementador y .env en una operación atómica.

cipi ini

Disponible desde v5.1.0. Una forma guiada de cambiar la configuración PHP sin buscar la correcto php.ini. Cada cambio en todo el servidor alcanza ambos SAPI — PHP-FPM y CLI: entonces, lo que ven sus solicitudes web es también lo que los trabajadores de la cola, artisan y cron ver.

$ cipi ini list                                # effective values and which layer set them
$ cipi ini list --app=shop                     # as seen by one app
$ cipi ini get memory_limit                    # one setting
$ cipi ini set upload_max_filesize=50M         # server-wide (FPM + CLI)
$ cipi ini set memory_limit=512M --app=shop    # for one app only
$ cipi ini unset memory_limit --app=shop       # fall back to the wider value
$ cipi ini reset [--app=shop]                  # back to Cipi defaults
$ cipi ini keys                                # what can be set, and what cannot

¿Qué hace por ti?

• Plantea las configuraciones que silenciosamente limitarían la tuya. Configuración upload_max_filesize también plantea post_max_size y memory_limit cuando de otro modo lo limitarían, y Nginx client_max_body_size está marcado cuando lo haría.
• Rechaza lo que no debería plantearse así. Las claves configurables son explícitas lista blanca - ver cipi ini keys. open_basedir, auto_prepend_file, extension y los amigos son rechazados por nombre, con la razon, porque Cipi los administra como parte del aislamiento de la aplicación.
• Las anulaciones por aplicación ganan. --app=<app> escribe en esa aplicación Grupo de FPM, que supera al archivo de todo el servidor, solo para esa aplicación.

¿Por qué era necesario arreglar esto?

Antes de 5.1.0, todos los grupos de FPM estaban codificados upload_max_filesize, post_max_size y max_execution_timey los valores del grupo superan conf.d - entonces un servidor completo php.ini El cambio no pudo llegar a una sola aplicación. Además de eso, Cipi escribió 99-cipi.ini solo para FPM, dejando el CLI SAPI (trabajadores de cola, artisan, cron) en los valores predeterminados del paquete PHP.

En 5.1.0, los grupos solo incluyen lo que es genuinamente por aplicación (open_basedir, el registro de errores, anulaciones explícitas) y heredar todo lo demás; ambos SAPI obtienen su expediente; y migración 5.1.0 rellena el CLI 99-cipi.iniy reescribe los grupos existentes en actualizar.

cipi db

Cipi crea una base de datos dedicada para cada Laravel aplicación automáticamente durante app create. MariaDB (puerto 3306) es el valor predeterminado nativo; desde v4.8.0 También puedes instalar opcional. PostgreSQL (puerto 5432) y elija un motor por base de datos o aplicación. Las aplicaciones personalizadas no obtienen una base de datos. usar cipi db create --name=<app>si necesita uno (por ejemplo, para WordPress u otro CMS). Después de la configuración, se muestra una URL de conexión lista para usar (MariaDB: mariadb+ssh://), combinando credenciales SSH, IP del servidor e información de la base de datos para GUI clientes como TablePlus, DBeaver o Sequel Pro.

Motores (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

Ciclo de vida de la base de datos

$ 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 aplicaciones almacenan el motor elegido en metadatos de la aplicación; copia de seguridad, sincronización y cipi app reset-db-password síguelo. uso cipi app create --engine=pgsql (o el mensaje interactivo) para aprovisionar una aplicación Laravel el PostgreSQL — .env y la URL de conexión coincide con el motor. Restablecer contraseña raíz: cipi reset db-password [--engine=].

cipi alias

Agregue múltiples dominios o subdominios a cualquier aplicación. Después de agregar alias, ejecute cipi ssl install para aprovisionar o renovar el certificado con cobertura SAN para todos dominios. desde v4.8.0, cipi alias add|remove regenera el vhost y vuelve a aplicar SSL con certbot install --redirectpor lo que HTTPS no se elimina.

$ cipi alias add myapp www.myapp.com
$ cipi alias add myapp myapp.it
$ cipi alias add myapp '*.miaplicación.com'   # wildcard (v5.1.0+) — quote it
$ cipi alias list myapp
$ cipi alias remove myapp myapp.it

desde v5.1.0, alias comodín como por ejemplo *.example.com se aceptan: Nginx coincide con un comodín server_namede forma nativa y las aplicaciones multiinquilino lo necesitan. Cita el patrón para que el caparazón no lo expanda y emitir el certificado con cipi ssl install myapp --dns=cloudflare --wildcard: HTTP-01 no puede validar un comodín.

Para redirecciones canónicas www ↔ apex, prefiera cipi www en lugar de gestionar el host homólogo manualmente.

cipi www

Disponible desde v4.8.0. Administre alias www/apex y redireccionamientos 301 canónicos para un aplicación. El estado vive en apps.json (www_redirect); Nginx emite un sonido dedicado bloque de servidor de redirección (la ruta ACME se mantiene pública) que sobrevive a la regeneración de vhost. SSL se vuelve a aplicar víacertbot 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 Agregue automáticamente el alias que falta cuando sea necesario.

cipi domains

Disponible desde v4.5.5. Un comando de nivel superior que enumera cada dominio y alias en todos aplicaciones en una sola tabla: la contraparte global de el por aplicación cipi alias list <app>. Ideal para auditar el conjunto mapeo de dominio a aplicación o detección de un dominio al que todavía le falta un certificado.

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

Cada fila muestra las siguientes columnas:

Un pie de página resume los totales (número de dominios, aplicaciones, certificados y aplicaciones suspendidas) que hacen Es fácil auditar todo el mapeo de un vistazo.

cipi ssl

Certbot gestiona Let's Encrypt certificados. Los certificados se renuevan automáticamente mediante un cron semanal. cipi ssl status muestra fechas de vencimiento con advertencias codificadas por colores: verde (>30 días), amarillo (14–30 días), rojo (<14 días).

$ 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

desde v4.8.0, cipi ssl force <app> vuelve a aplicar el HTTP → HTTPS redireccionamiento para una aplicación que ya tiene un certificado Let's Encrypt, sin emitir uno nuevo. cipi ssl install también establece force_https en apps.json automáticamente.

desde v5.0, opcional DNS-01 Los desafíos a través de Cloudflare reemplazan el flujo predeterminado HTTP-01 cuando necesita certificados comodín o no puede exponer el puerto 80. Configure una vez con cipi ssl dns set, luego pasa --dns=cloudflare (y opcionalmente --wildcard) a cipi ssl install.

cipi nginx default-server

Disponible desde v5.1.0. Reclamaciones cualquiera de :80 / :443 no tiene un servidor predeterminado y cierra las solicitudes no coincidentes con una respuesta vacía (444).

$ cipi nginx default-server status
$ cipi nginx default-server on
$ cipi nginx default-server off

Cipi siempre tuvo un servidor predeterminado en :80, pero nunca en :443. Un HTTPS solicitud que lleva un desconocido Host por lo tanto cayó en cualquier vhost Nginx que hubiera cargado primero: para una aplicación multiinquilino comodín, directamente en un solucionador de inquilinos que no puede analizar eso.

Está habilitado en instalaciones nuevas y migración 5.1.0 lo reclama en servidores existentes donde ya nada más lo hace. Si otro vhost posee legítimamente el servidor predeterminado, el comando lo dice y no cambia nada.

cipi backup

Realice una copia de seguridad de los archivos de aplicaciones y bases de datos en el disco local, en Amazon S3 o en cualquier dispositivo compatible con S3. proveedor (Cloudflare R2, Hetzner Object Storage, DigitalOcean Spaces, Backblaze B2, Scaleway, MinIO,…).

desde v5.1.0 las copias de seguridad son impulsadas por perfiles en lugar de uno trabajo nocturno codificado. Un perfil responde a cuatro preguntas: que se necesita, con qué frecuencia corre, donde va y cuanto tiempo eso se mantiene, y los perfiles son independientes, por lo que una copia de 30 minutos de la base de datos guardada en el disco se guarda felizmente junto a una copia completa nocturna cifrada en S3.

1 - Destinos

cipi backup configure almacena las S3 credenciales compartidas por cada perfil. desde v5.1.0 puedes dejar el cubo vacío para copias de seguridad solo locales, bajo qué tierra /var/backups/cipi.

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

$ cipi backup status                 # destinations, profiles, last run, overdue

Puntos finales compatibles con S3

2 — Perfiles de respaldo

Crea un perfil una vez; luego se ejecuta según su propio horario. Dos típicos:

# Every 30 minutes — databases only, kept on the server, last 48 runs
$ cipi backup profile add hourly-db --scope=db \
      --databases='tienda,inquilino_*' --exclude-tables='*.trabajos,*.telescopio_*' \
      --every=30m --keep=48 --dest=local

# Every night at 02:00 — files + databases, encrypted to S3, kept 14 days
$ cipi backup profile add nightly --scope=all \
      --cron='0 2 * * *' --keep-days=14 --dest=s3 --encrypt

$ cipi backup profile list                 # all profiles
$ cipi backup profile show nightly         # one profile in detail
$ cipi backup profile edit nightly --keep-days=30
$ cipi backup profile disable hourly-db    # pause it without deleting it
$ cipi backup profile enable hourly-db
$ cipi backup profile remove hourly-db     # deletes the profile, keeps its archives

Banderas para profile add / profile edit

3 - Cifrado

con --encrypt el archivo está cifrado con AES-256 en el servidor, antes de cargarlo, por lo que el operador del depósito nunca contiene datos legibles. El manifiesto sigue siendo legible por lo que aún se puede identificar una carrera.

$ cipi backup key show      # print the key — store it off-server
$ cipi backup key rotate    # new key for future runs

4 — Ejecutar, comprobar y restaurar

$ cipi backup run                          # run every enabled profile now
$ cipi backup run --profile=nightly        # run one profile now
$ cipi backup run --dry-run                # show what it would take, take nothing
$ cipi backup list [--profile=nightly]     # runs held on each destination
$ cipi backup verify                       # does the newest run of each profile open?
$ cipi backup verify --deep                # same, downloading from S3 to check
$ cipi backup prune [--profile=nightly]    # apply retention now
$ cipi backup fetch nightly 2026-09-02_020000   # download and decrypt one run

desde v5.1.0 Estos comandos te dicen la verdad en lugar de tranquilizarte:

• Cada archivo es integridad comprobada antes de enviarse. Un vertedero interrumpido por un completo el disco todavía es un archivo que no está vacío, por lo que la verificación de tamaño anterior pasó; ahora hay un archivo corrupto descartado e informado en lugar de reemplazar silenciosamente una buena copia de seguridad.
• cipi backup fetch ya no informa éxito en un prefijo que no contiene objetos, por lo que un La marca de tiempo mal escrita es un error en lugar de un directorio vacío.
• cipi backup verify dice claramente que no hay nada que verificar cuando no se ha realizado ninguna ejecución sucedió todavía, en lugar de “pasado”.
• tar advertencias: "el archivo cambió a medida que lo leímos", constante en una aplicación en vivo que escribe su logs: ya no fallará un archivo en perfecto estado. Sólo cuenta el código de salida 2 y superior.
• A discapacitado El perfil realmente deja de ejecutarse y Encrypted es mostrado correctamente.

Para restaurar, busque la ejecución y retroalimente las piezas:

$ cipi backup fetch nightly 2026-09-02_020000 --dest=/root/restore
$ cipi db restore myapp /root/restore/databases/mariadb/myapp.sql.gz
$ tar -tzf /root/restore/apps/myapp/files.tar.gz

5 - Diseño de almacenamiento

Los archivos de aplicaciones y las bases de datos se almacenan. por separado, con un manifiesto por ejecución, por lo que un perfil de solo base de datos no cuesta nada y una base de datos se puede restaurar sin desempaquetar un aplicación.

<root>/<profile>/<YYYY-MM-DD_HHMMSS>/
├── manifest.json
├── apps/
│   └── myapp/
│       ├── files.tar.gz
│       └── meta.json
└── databases/
    └── mariadb/
        └── myapp.sql.gz

# local  → /var/backups/cipi/<profile>/<timestamp>/
# s3     → s3://<bucket>/cipi/<profile>/<timestamp>/

El valor predeterminado de la preparación de la copia de seguridad es /var/tmp (disco) en lugar de /tmp (a menudo un pequeño tmpfs respaldados por RAM), por lo que las aplicaciones grandes no fallan a mitad de la copia de seguridad cuando tmpfs se llena. Anular con tmpdir en backup.json (establecido a través de cipi backup configure) o el CIPI_BACKUP_TMPDIR variable de entorno.

6 - Horario y el organismo de control de la obsolescencia

Ya no escribes cron líneas a mano. cipi backup configurey cada cambio de perfil reescribir un bloque marcado en el crontab de root; todo lo que esté fuera de ese bloque queda solo, y las líneas escritas a mano anteriores a 5.1 se absorben en la migración.

Un perro guardián cada hora eleva el backup_stalenotificación cuando un perfil no ha tenido éxito dentro del doble de su propio intervalo, porque una copia de seguridad que silenciosamente dejó de ejecutarse es peor que ninguna copia de seguridad: todavía parece configurada. Un perfil recién creado no se informa como vencido antes de que pudiera haber ocurrido su primera ejecución programada.

Poda heredada

cipi backup prune <app> --weeks=N sigue trabajando en contra del diseño anterior a 5.1 (s3://<bucket>/cipi/<app>/<timestamp>/ además de volcados previos a la implementación en /var/log/cipi/backups), por lo que los archivos existentes y cualquier línea cron escrita a mano aún podar. Uso de nuevos perfiles --keep, --keep-days o --keep-weeks en cambio.

crontab de usuario

Cipi agrega automáticamente una entrada crontab para el programador Laravel cuando se crea una aplicación:

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

Esta entrada se ejecuta como myapp usuario de Linux cada minuto, utilizando la versión PHP seleccionada para la aplicación. Se actualiza automáticamente cuando cambia la versión PHP a través de cipi app edit myapp --php=X.

Ver el crontab actual

# 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

Agregar trabajos cron personalizados

Puede agregar cron trabajos adicionales al crontab del usuario de la aplicación. Cambie primero al usuario de la aplicación para garantizar trabajos ejecutar con el contexto de usuario y permisos de archivo correctos:

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

Entradas de ejemplo que podría agregar:

# 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

Comprobando si cron está funcionando

# 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

desde v5.0, administre la entrada crontab del programador Laravel que se ejecuta schedule:run (el crontab en sí ya existía; ahora se puede alternar y rastrear en apps.json).

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

cipi worker & Laravel Horizon

Cada aplicación obtiene un trabajador Supervisor predeterminado para la default cola. Puedes agregar adicionales colas con recuentos de procesos personalizados y tiempos de espera.

$ 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

con Horizon habilitado, implementar ejecuciones horizon:terminate y se reinicia trabajadores vía cipi-worker. No puedes ejecutar clásico queue:work trabajadores y Horizon en la misma aplicación a la vez.

Los trabajadores de la cola también se pueden declarar en el repositorio de la aplicación; consulte cipi.yml.

Los trabajadores se detienen antes del intercambio de enlaces simbólicos y se reinician después de cada implementación, lo que evita Supervisor por recoger obsoletoartisan caminos. Supervisor está configurado con autorestart=unexpected por lo que los trabajadores sólo se reinician en salidas inesperadas, no en salidas elegantes. se detiene.

Ayudante de usuario de la aplicación: cipi-worker

Cada usuario de la aplicación puede reiniciar, detener o verificar trabajadores sin root, a través de un asistente restringido sudo instalado en /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

Como root, usecipi worker list|restart|stop <app> en cambio. no hay cipi worker status comando de administrador - usar cipi worker list o el usuario de la aplicación ayudante arriba.

cipi health

desde v5.0, configure HTTP controles de estado por aplicación. Cipi luego mira la aplicación en dos diferentes maneras, porque "¿está activo el sitio?" y "¿El empujón que acabo de hacer interrumpió la producción?" no son la misma pregunta.

$ 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

Verificación posterior a la implementación (v5.1.0+)

Una vez que una aplicación tiene una URL de verificación de estado, la versión que acaba de lanzarse se verifica inmediatamente después de cada implementar - desde cipi deploy y desde Git webhook por igual. La sonda espera una breve gracia. período (8 segundos para Octane aplicaciones, 3 en caso contrario, o lo que sea --grace=N dice) y lo vuelve a intentar cinco veces, por lo que La aplicación que necesita un momento para aparecer no se informa como rota.

El veredicto nunca cambia el código de salida de la implementación (el lanzamiento está activo de cualquier manera), pero la alerta lo dice y le entrega el comando de reversión. Se envía el correo electrónico de éxito. después verificación, por lo que nunca podrá anunciar una implementación exitosa mientras el sitio devuelva 500.

$ cipi health postdeploy myapp             # run the post-deploy verification now
$ cipi health set myapp --grace=15         # give the release longer to warm up (max 120)
$ cipi health set myapp --no-postdeploy    # turn the post-deploy check off for this app

Reversión automática de una versión en mal estado (optar por participar)

Cipi puede deshacer una versión que no pasa su verificación de estado posterior a la implementación: current enlace simbólico vuelve a la versión anterior, la aplicación se prueba nuevamente y uno correo electrónico describe toda la secuencia: qué se publicó, qué respondió, a qué se revirtió y si eso lo solucionó.

$ cipi health set myapp --rollback-on-unhealthy   # permanent, per app
$ cipi deploy myapp --rollback-on-unhealthy       # just this deploy

Se informan claramente cuatro resultados: recuperado; retrocedido pero aún insalubre (por lo que la causa probablemente no sea el código); la reversión en sí falló (el lanzamiento incorrecto aún está activo); y no hay ninguna versión anterior para volver a.

DESCANSO: GET /api/health, GET|PUT|DELETE /api/apps/{name}/health, POST /api/apps/{name}/health/check (API 1.15.0+ / Cipi 5.0.6+). Una aplicación también puede declarar su verificación de estado en su repositorio; consulte cipi.yml.

cipi firewall

Cipi instala UFW con los puertos 22, 80 y 443 abiertos de forma predeterminada. Utilice los comandos del firewall para administrar reglas adicionales sin tocar UFW directamente.

$ 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

Inspeccione y administre las prohibiciones de Fail2ban directamente desde el CLI. Cipi configura Fail2ban con progresivo prohibición: una prohibición básica de 24 horas que se duplica con cada infracción repetida hasta un límite de 7 días, con un máximo de reintentos reducido a 3. Un dedicado recidiveLa cárcel prohíbe a los reincidentes durante 7 días después de 3 prohibiciones. dentro de las 24 horas.

$ 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

Enumera todas las IP actualmente prohibidas por Fail2ban, agrupadas por cárcel (p. ej. sshd, recidive). Útil para un control de seguridad rápido o antes de ejecutar una desbanificación.

cipi ban unban <IP>

Elimina la IP proporcionada de todos Fail2ban cárceles a la vez. Útil cuando un usuario legítimo o el corredor de CI queda bloqueado por error.

cipi service

Verifique y controle los servicios del sistema que alimentan Cipi directamente desde el CLI. Nginx usa un elegante recarga (tiempo de inactividad cero) en lugar de un reinicio completo.

$ 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

DESCANSO: GET /api/services, POST /api/services/{name}/restart (API 1.15.0+ / Cipi 5.0.6+; habilidades services-view / services-manage).

Nombres de servicios admitidos: nginx, mariadb, postgresql (alias: pgsql, postgres — cuando se instala mediante cipi db install pgsql), valkey-server, supervisor, fail2ban, php<ver>-fpm (por ej.php8.5-fpm). La palabra clave php apunta a todas las versiones PHP-FPM instaladas a la vez. Para el backend de caché, redis-server, redis, y valkey son aceptados como alias de valkey-server.

Valkey, la bifurcación compatible con Redis y con licencia BSD, se incluye en la pila predeterminada y reemplazaredis-server desde Cipi 4.5.6. Se instala con una contraseña, vinculada a localhostúnicamente, y sus credenciales (usuario, contraseña) se guardan en /etc/cipi/server.json y se muestra al final de la instalación. valkey-server se agrega a la lista negra de actualizaciones desatendidas: Cipi lo administra, por lo que es no se actualiza automáticamente. Ver el Valkey sección para más detalles y la migración automática Redis → Valkey.

cipi ssh — Gestión de claves SSH

Gestionar las claves SSH autorizadas para el cipi usuario: el punto de entrada SSH del administrador. el cipi usuario (grupo cipi-ssh) utiliza únicamente clave pública; El inicio de sesión raíz está deshabilitado. Usuarios de la aplicación (grupo cipi-apps) conectarse con contraseña — ver SSH como el usuario de la aplicación.

Comandos

$ 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

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

Mecanismos de seguridad

cipi ssh remove incluye dos salvaguardas para evitar el bloqueo:

• Protección de la sesión actual — no puedes eliminar la clave utilizada por tu SSH activo sesión.
• Protección de última clave — No puede eliminar la última clave autorizada restante.

Comentarios clave

Las claves SSH se almacenan con sus comentarios originales intactos, lo que facilita identificar quién es cada clave. pertenece a. uso cipi ssh rename para cambiar el nombre para mostrar de cualquier tecla:

# list keys to find the number
$ cipi ssh list

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

Notificaciones por correo electrónico

Cuando se configura SMTP, Cipi envía una alerta por correo electrónico cada vez que se agrega, elimina o cambia el nombre de una clave. La notificación incluye el nombre de host del servidor, la dirección IP, la huella digital de la clave, el comentario de la clave, la marca de tiempo, y el número de claves restantes. Las notificaciones de cambio de nombre también incluyen el nombre de la clave nueva y antigua.

cipi — Servidor y actualización automática

Comandos de nivel superior para el estado del servidor y la autogestión Cipi.

$ 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

Restablecimiento de contraseña y credenciales

Cipi proporciona comandos para regenerar contraseñas a nivel de servidor. Las nuevas contraseñas se almacenan en /etc/cipi/server.json (cifrado a través de Vault) y mostrado en la pantalla. Guárdalos inmediatamente — se muestran solo una vez.

$ 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