Comandos del appliance

Los comandos ironflock appliance instalan el appliance de IronFlock en un servidor Linux que gestionas tú mismo, y lo mantienen a partir de entonces. Con ellos instalas el appliance, cambias sus ajustes, lo actualizas, lo inicias, lo detienes y lo reinicias, lees sus registros, restableces la contraseña de admin, haces copia de seguridad de sus secretos, los restauras y los rotas, y lo vuelves a eliminar.

El appliance es el sistema IronFlock completo en una máquina en tus instalaciones. Qué es, sus modos HTTPS, su red y su operación se describen en IronFlock Appliance. Los requisitos de la máquina (CPU, memoria, almacenamiento, sincronización horaria) están en su página Instalación.

Nota: Estos comandos son nuevos en el release 2.1.0 de ironflock. Han superado una ejecución de prueba, de appliance install a appliance remove --purge, en una máquina virtual nueva con Ubuntu 24.04 (amd64). Todavía no está probada una actualización que falla, con su reversión al release anterior.

El appliance

Los comandos del appliance se ejecutan en Linux. appliance install necesita un sistema basado en Debian o Ubuntu con systemd. En macOS, los comandos terminan con el código de salida 3 antes de examinar nada; ejecútalos en la máquina del appliance, o desde el Mac con --host.

Ejecútalos como root, con sudo. Sin root, un comando que cambia el sistema termina con el código de salida 3, y no llama a sudo por sí mismo (Privilegios de root).

Cada comando acepta además los flags globales --yes, --json, --download-base, --host, --hosts y --parallel (Flags globales). Una pregunta necesita una terminal; sin ella, indica --yes (Preguntas y confirmación).

ironflock status muestra el appliance instalado: su versión y su canal, la dirección de su UI, si tiene licencia, su servicio, la salud de sus servicios y una actualización pendiente (ironflock status).

Cómo es un appliance instalado

Además de ironflock.service, la instalación configura un watchdog, que comprueba el router y el backend cada cinco minutos y reinicia ironflock.service cuando no están bien, como máximo una vez cada cinco minutos, y un temporizador que vuelve a intentar cada hora una actualización fallida de la UI.

Mantén /usr/local/bin/ironflock en su sitio: las unidades del appliance lo ejecutan en cada inicio. appliance install se niega a ejecutarse desde otro lugar e indica cómo instalarlo allí. ironflock status, ejecutado como root, advierte cuando ese binario falta o es más antiguo que el que instaló o actualizó el appliance por última vez. sudo ironflock self-update lo reemplaza por el release más reciente (ironflock self-update).

El appliance ejecuta además el agente del dispositivo propio del host, que appliance install instala salvo que indiques --no-agent. Ese agente se gestiona con los comandos agent.

Un cambio cada vez

Solo se ejecuta a la vez una instalación, una actualización u otro cambio del appliance. Un segundo espera al primero y lo indica:

Another IronFlock install, update or other change of the appliance is running on this host (process <pid>); waiting up to <time> for it to finish

install, update, configure, rotate, revoke-direct-access, reset-admin-password y restore esperan hasta una hora. start, stop, restart y remove esperan hasta 30 segundos. Si la otra ejecución sigue entonces en marcha, el comando no cambia nada y termina con el código de salida 3.

ironflock appliance install

Instala el appliance de IronFlock en /opt/ironflock y lo inicia. Espera hasta que todos los servicios estén sanos y la nube de IronFlock alcance el appliance, y después muestra el inicio de sesión de admin de la UI web, una sola vez, en una terminal.

ironflock appliance install --license-file <file> [flags]

Se ejecuta en: un Linux basado en Debian o Ubuntu con systemd. Root: necesario.

La instalación configura:

• el release del canal, o el que indica --version, comprobado con la clave de release del appliance;
• la configuración y los secretos del appliance;
• el agente del dispositivo propio del host, y Docker cuando falta;
• los ajustes del host;
• el inicio de sesión de Docker en el registro con la clave de licencia;
• las imágenes del release;
• ironflock.service.

Cuando falta Docker, la instalación ejecuta como root el script de instalación de Docker de get.docker.com. Esa descarga solo está protegida por TLS.

Los modos HTTPS y lo que cifra cada uno se describen en HTTPS y certificados y Seguridad. La contraseña del proxy sigue las reglas de Secretos: una URL de proxy con contraseña es una línea de comandos incorrecta.

La clave de licencia

La clave de licencia es la Instance Key que creas en ironflock.com en Perfil → Instancias (Instalación). Viene de --license-file o de --license. Un appliance que ya está instalado conserva su clave sin ninguno de los dos. Todos los comandos del appliance ignoran, con una advertencia, una clave de license.env que no es una clave de licencia válida (una clave de licencia es un UUID); la ejecución necesita entonces una clave, o --skip-login.

Variables de entorno

Algunos flags toman su valor por defecto de una variable de entorno:

sudo descarta la mayoría de las variables de tu shell. Pásalas con sudo env NAME=value ironflock appliance install ....

El registro de las elecciones de la instalación

<install-dir>/install.json, exclusivo de root, guarda las elecciones que no guardan ni .env ni las unidades: el registro y su usuario, el host del appliance (IRONFLOCK_APPLIANCE_HOST), --no-agent, la base de descarga de --bucket-url y la versión del ironflock que instaló o actualizó el appliance por última vez. No contiene ninguna contraseña, token ni clave.

Un appliance install posterior, un appliance update y appliance configure conservan estas elecciones salvo que un flag (o su variable) diga otra cosa. Un flag indicado tiene prioridad y se registra. Para volver a un valor por defecto, indica --registry "", --no-agent=false o un IRONFLOCK_APPLIANCE_HOST vacío.

Un registro que no se puede leer, o uno de un formato posterior, detiene install, update y configure antes de que cambien nada, con el código de salida 3. El mensaje dice qué hacer: apartar el registro y volver a instalar con los flags, o usar el ironflock más reciente.

Volver a ejecutarlo

Ejecutado en un appliance instalado, el comando lo lleva al release y a las opciones indicados, y conserva sus secretos y ajustes. Úsalo para cambiar el release a propósito: ironflock appliance install --version <version> descarga, reinicia y comprueba de nuevo ese release, también cuando ya se está ejecutando.

Una ejecución que se detuvo continúa desde donde se detuvo cuando se vuelve a ejecutar el mismo comando.

Una vez superadas sus comprobaciones de salud, la instalación elimina la copia de un release anterior que conservó una actualización (/opt/ironflock/.update-previous): el release que instaló es el que se debe ejecutar.

A partir de su primer cambio, una terminal o una sesión SSH perdida (SIGHUP), o una salida que ya nadie lee (una tubería cerrada), no detiene la instalación. Ctrl-C y SIGTERM sí. La instalación sigue escribiendo en la terminal tras perder una sesión SSH, para que no se pierda la contraseña de admin. Por eso, con el ajuste use_pty de sudo, una terminal que sigue abierta pero que ya no se lee puede bloquear la instalación mientras esta tiene el bloqueo de instalación.

Ejemplos

# Instalar el appliance; la clave de licencia viene de un archivo
sudo ironflock appliance install --license-file license.txt
# Instalar con HTTPS de la CA propia del appliance; la clave viene de la entrada estándar
sudo ironflock appliance install --license-file - --tls < license.txt
# Instalar detrás de un proxy; los hosts bajo .corp.example.com lo eluden
sudo ironflock appliance install --https-proxy http://proxy.example.com:3128 --no-proxy .corp.example.com
# Preguntar la dirección y el dominio del appliance, e instalar con HTTPS
sudo ironflock appliance install --license-file license.txt --interactive --tls

Cuándo se niega y cuándo falla

• Una base de descarga de --bucket-url que las unidades no pueden indicar tal cual (con credenciales, %, espacios en blanco, $, \, una comilla, un carácter de control, bytes que no son UTF-8) se rechaza antes de que se escriba nada, con el código de salida 2.
• El comando se niega con el código de salida 3 cuando no se ejecuta como root, cuando no se puede leer el registro de las elecciones de la instalación y cuando otra ejecución mantiene el bloqueo de instalación más allá de la espera de una hora. También se niega cuando el ironflock que se ejecuta no es /usr/local/bin/ironflock, e indica cómo instalarlo allí.
• Un paso que falla termina el comando con el código de salida 1. Ejecuta el mismo comando de nuevo para continuar.

ironflock appliance configure

Cambia los ajustes de un appliance instalado: su licencia, el modo TLS (también con un certificado propio), el proxy, más nombres de host para la UI, el túnel y la política de segundo factor.

ironflock appliance configure [flags]

Se ejecuta en: Linux, con un appliance instalado. Root: necesario.

Los ajustes se quedan en el .env y los archivos del appliance, así que una actualización los conserva. Un ajuste que no se indica conserva lo que tiene el appliance. Solo una ejecución que cambió algo reinicia el appliance, así que el mismo comando dos veces no cambia nada la segunda vez.

• Una licencia nueva (--license, --license-file, o --license-file - para la entrada estándar) tiene que dar acceso al registro antes de que se escriba. Su inicio de sesión en el registro va a --registry como --registry-user o, si no, a los que eligió la instalación (el registro) o, si no, al registro desde el que sincroniza la réplica del appliance. Un inicio de sesión con --registry o --registry-user los guarda en el registro para las actualizaciones.
• --tls-cert y --tls-key instalan tu certificado y activan TLS, y los dispositivos pasan al dominio del appliance.
• --http-proxy "" o --https-proxy "", indicados solos, borran el proxy.
• --no-agent de la instalación se queda como estaba.
• El Caddyfile que necesita TLS viene de --bucket-url o, si no, de donde la instalación tomó los releases.

Ejemplos

# Dar al appliance una clave de licencia nueva desde un archivo
sudo ironflock appliance configure --license-file license.txt
# Servir la UI con el certificado de tu organización
sudo ironflock appliance configure --tls-cert wildcard.crt --tls-key wildcard.key
# Definir un proxy y volver a borrarlo
sudo ironflock appliance configure --https-proxy http://proxy.example.com:3128 --no-proxy .corp.example.com
sudo ironflock appliance configure --https-proxy ""
# Exigir un segundo factor a todos los usuarios
sudo ironflock appliance configure --2fa required

Antes de definir --2fa required, asegúrate de que todas las cuentas tienen un segundo factor: un usuario sin él ya no puede iniciar sesión (Cuentas y acceso).

Cuándo se niega

El comando se niega con el código de salida 3, y no cambia nada, cuando no se ejecuta como root, cuando no se puede leer el registro de las elecciones de la instalación, cuando otra ejecución mantiene el bloqueo de instalación más allá de la espera de una hora, y mientras una actualización ha quedado a medias (Cuando una actualización quedó a medias).

ironflock appliance update

Actualiza el appliance de esta máquina al release más reciente de su canal, o al release que indica --version. El release se comprueba con la clave de release del appliance, se descargan sus imágenes y el appliance se reinicia con él. El comando espera hasta que todos los servicios estén sanos y la nube de IronFlock alcance el appliance. El appliance conserva sus secretos y ajustes. Las imágenes de releases anteriores se eliminan una vez que el nuevo está sano.

ironflock appliance update [flags]

Se ejecuta en: Linux, con un appliance instalado. Root: necesario. Pregunta: nada, salvo con --discard-previous.

Los releases vienen de --bucket-url; si no, de IRONFLOCK_BUCKET_URL; si no, de donde los tomó la instalación (lo indican el registro de sus elecciones, /opt/ironflock/install.json, o sus unidades); si no, de IronFlock. El registro, su usuario, el host del appliance y --no-agent se quedan como los eligió la instalación.

Un canal nuevo se mantiene cuando la actualización sale bien; con una reversión vuelve el canal anterior. Apply update de la UI ejecuta la misma actualización.

Una vez superadas sus comprobaciones, una instalación o una actualización también cambia el dispositivo propio del appliance del secreto que antes compartían todos los appliances al valor de APPLIANCE_DEVICE_SECRET. Su agente se reinicia entonces 35 segundos después de la ejecución. Un cambio que no se puede hacer es una advertencia que dice por qué; la siguiente instalación o actualización lo vuelve a intentar.

Ya está al día

Un appliance que ya ejecuta el release más reciente de su canal (o el release que indica --version), en el mismo canal y con la misma base de descarga, se deja como está. El comando lo indica y termina con el código de salida 0; con --json, el result es nothing-to-do. Para descargar, reiniciar y comprobar de nuevo ese release a propósito, ejecuta ironflock appliance install --version <version>.

Esto solo vale para un appliance que la última actualización dejó en orden. Con una copia conservada de un release anterior (una actualización que quedó a medias), o con un archivo de estado que dice failed o running, la actualización vuelve a ejecutarlo todo.

Reversión

Antes de cambiar nada, la actualización guarda los archivos del release en ejecución en /opt/ironflock/.update-previous. Cuando la actualización falla después de haber cambiado el appliance, esos archivos se restauran y el release anterior vuelve a arrancar. Esto no necesita red, ya que sus imágenes están en la máquina. Se intenta hasta tres veces. Después, el comando desiste y deja en su sitio los archivos del release anterior, de modo que el siguiente inicio del appliance sea ese release.

Una actualización que falla antes de cambiar nada no cambia nada más y lo indica: por ejemplo, un release que no existe o que no está firmado, o una base de descarga que no responde.

Un release puede necesitar un ironflock más reciente que el que se ejecuta. Entonces no se cambia nada, y el comando indica qué ironflock instalar primero. appliance update no actualiza ironflock por sí mismo; ironflock self-update instala el más reciente.

Archivo de estado y reintento

La actualización escribe su progreso en triggers/apply-update.status, como hace la actualización de la UI, así que la UI lo muestra. Su salida va también a triggers/apply-update.log. El temporizador que vuelve a intentar una actualización fallida de la UI no vuelve a intentar una actualización de este comando que falló, o que se detuvo antes de cambiar nada.

Interrupciones

• Ctrl-C o SIGTERM antes de que la actualización cambie nada la detienen. Después, el primero restaura el release anterior (código de salida 130), y un segundo la detiene de inmediato.
• Una terminal o una sesión SSH perdida (SIGHUP), o una salida que ya nadie lee, no detiene la actualización. La actualización, y una reversión, se ejecutan hasta el final. El archivo de estado e ironflock status dicen cómo terminó.
• Con --host sin terminal, los dos primeros Ctrl-C llegan a la máquina. Tras el primero, el comando espera hasta 30 minutos a que termine allí la actualización; tras el segundo, 15 segundos; un tercero lo termina aquí de inmediato. Una sesión perdida aquí, o SIGTERM, no es un Ctrl-C: el comando termina aquí de inmediato. Siempre que termina aquí primero, la actualización sigue en la máquina, e ironflock --host <machine> status muestra cómo terminó.

Cuando una actualización quedó a medias

Una actualización queda a medias cuando empezó a cambiar el appliance y después no terminó: se detuvo, la máquina se apagó, o su reversión no levantó el release anterior. El directorio de instalación puede contener entonces archivos de dos releases. La copia conservada indica el release que se sabe que funciona, e ironflock status también lo indica.

• La siguiente actualización restaura primero esa copia y después actualiza. Una copia que no se puede leer ni restaurar detiene la actualización con el código de salida 3, y el error indica ironflock appliance install --version <version>.
• El temporizador de reintento cada hora restaura la copia por sí solo, reinicia ese release y lo comprueba, también cuando no existe ningún release más reciente.
• configure, rotate, revoke-direct-access, restore y reset-admin-password se niegan antes de cualquier cambio, con el código de salida 3. Indican las tres salidas: ironflock appliance update; ironflock appliance install --version <version>; y, sin red, ironflock appliance update --discard-previous.
• backup solo lee, y advierte. start, stop y restart no tocan la copia. remove elimina la copia con el resto de los archivos del appliance.
• appliance install se ejecuta como siempre y, una vez superadas sus comprobaciones de salud, elimina la copia.

Para trabajar a mano con los archivos de una actualización que quedó a medias, define primero IRONFLOCK_UPDATE_RETRY=off en .env. Si no, el temporizador de reintento restaura el release anterior en aproximadamente una hora. Ese ajuste desactiva el temporizador de reintento por completo, incluida su reversión.

--discard-previous

ironflock appliance update --discard-previous [--yes]

No actualiza nada. Elimina la copia del release anterior que conservó una actualización (/opt/ironflock/.update-previous), en cualquier estado y también cuando no se puede leer, y no cambia nada más. No necesita red.

Es la salida sin red cuando una actualización quedó a medias y su release anterior no vuelve a arrancar. Los archivos del directorio de instalación se quedan como están ahora, ese release ya no se puede restaurar, y los comandos que se negaban vuelven a ejecutarse.

Dice lo que elimina y pregunta antes, con «No» preseleccionado; --yes responde sí. Sin terminal, o con --json, necesita --yes; si no, termina con el código de salida 4. Sin copia, lo indica y termina con el código de salida 0. No se puede combinar con --version, --channel ni --bucket-url (código de salida 2). Con --json, el resultado tiene action (discarded, cleaned o none), path, version, state y removed.

Ejemplos

# Actualizar al release más reciente del canal
sudo ironflock appliance update
# Instalar el release 1.6.41, también para volver a él
sudo ironflock appliance update --version 1.6.41
# Cambiar al canal test y leer el resultado como JSON
sudo ironflock appliance update --channel test --json
# Eliminar la copia del release anterior, sin red
sudo ironflock appliance update --discard-previous

Resultado

{"from":"1.6.40","target":"1.6.41","version":"1.6.41","result":"updated"}

Una actualización fallida es un error que dice si el appliance volvió al release anterior. Con --json, su kind es uno de estos, también cuando se interrumpió:

ironflock appliance start

Inicia el appliance cuando no se está ejecutando: ironflock.service inicia sus contenedores (docker compose up), y su watchdog y sus demás paths y temporizadores vuelven a arrancar. Los servicios tardan uno o dos minutos en levantarse; ironflock status muestra su salud.

ironflock appliance start [flags]

Se ejecuta en: Linux, con un appliance instalado. Root: necesario. Pregunta: nada. El comando no tiene flags propios.

Cuando una restauración dejó roles de la base de datos con sus contraseñas antiguas, porque el appliance no estaba en marcha entonces, estos toman las contraseñas del .env restaurado en cuanto sus bases de datos se ejecutan (hasta un minuto). Un rol que no responde queda para el siguiente inicio, con una advertencia, y el inicio continúa.

sudo ironflock appliance start
sudo ironflock appliance start --json

Mientras otra ejecución cambia el appliance, el comando espera hasta 30 segundos y lo indica; si esa ejecución sigue, no cambia nada y termina con el código de salida 3.

ironflock appliance stop

Detiene el appliance: su watchdog y sus demás paths y temporizadores, y lo que estos iniciaron; después ironflock.service, que detiene y elimina sus contenedores (docker compose down). Sus datos se conservan.

ironflock appliance stop [flags]

Se ejecuta en: Linux, con un appliance instalado. Root: necesario. Pregunta: sí, después de decir qué termina al detenerlo; --yes responde.

La UI deja de estar en línea, y también todos los dispositivos que se conectan al appliance, incluido el agente de esta máquina. ironflock appliance start vuelve a iniciar el appliance, y también lo hace el siguiente arranque del sistema. El comando no tiene flags propios.

# Detener el appliance; el comando dice qué termina con ello y pregunta
sudo ironflock appliance stop
# Detenerlo sin pregunta
sudo ironflock appliance stop --yes

La respuesta no, o una pregunta sin terminal y sin --yes, termina el comando con el código de salida 4. Mientras otra ejecución cambia el appliance, el comando espera como lo hace start.

ironflock appliance restart

Reinicia el appliance: ironflock.service detiene sus contenedores y los vuelve a iniciar (docker compose down y después up), como hace su watchdog. Los paths y temporizadores que detuvo appliance stop vuelven a arrancar.

ironflock appliance restart [flags]

Se ejecuta en: Linux, con un appliance instalado. Root: necesario. Pregunta: nada. El comando no tiene flags propios.

La UI y los dispositivos que se conectan al appliance quedan sin conexión durante uno o dos minutos; sus datos se conservan. ironflock status muestra la salud de los servicios una vez que se han levantado. Los roles de la base de datos que una restauración dejó con sus contraseñas antiguas toman las de .env, como con start.

sudo ironflock appliance restart
sudo ironflock appliance restart --json

Mientras otra ejecución cambia el appliance, el comando espera como lo hace start.

ironflock appliance logs

Muestra lo que escribieron los servicios del appliance, como lo muestra docker compose logs: por defecto, las últimas 100 líneas de cada servicio. No cambia nada.

ironflock appliance logs [<service>...] [flags]

Se ejecuta en: Linux, con un appliance instalado. Root: necesario. Pregunta: nada.

Indica servicios para ver solo los suyos, como router, backend, kratos o caddy.

Con --json, cada línea es un objeto JSON, con la línea como su mensaje.

# Las últimas 100 líneas de cada servicio
sudo ironflock appliance logs
# Todo lo que escribió el backend en la última hora
sudo ironflock appliance logs backend --since 1h
# Las últimas 20 líneas del router y de Kratos, y después cada línea nueva hasta Ctrl-C
sudo ironflock appliance logs router kratos --follow --lines 20

ironflock appliance reset-admin-password

Da una contraseña nueva al usuario admin de la UI, para un operador que la perdió. La contraseña se define primero en la base de datos, lo que cierra todas las sesiones activas del admin, y después en .env como APPLIANCE_ADMIN_PASSWORD. El appliance tiene que estar en marcha.

ironflock appliance reset-admin-password [flags]

Se ejecuta en: Linux, con un appliance en marcha. Root: necesario.

La contraseña nueva se muestra una sola vez, y solo en una terminal. Sin terminal, y con --json, el comando indica en su lugar dónde está guardada. Se niega con el código de salida 3 mientras una actualización ha quedado a medias (Cuando una actualización quedó a medias).

sudo ironflock appliance reset-admin-password

ironflock appliance backup

Escribe en un archivo tar.gz todo lo del appliance que no se puede volver a generar: .env con todos los secretos, license.env, la CA local del certificado TLS, el par de claves de los tokens del registro, el inventario de secretos y rotation.log.

ironflock appliance backup [-o <file>] [flags]

Se ejecuta en: Linux. Root: necesario.

Sin -o, el archivo comprimido va a la salida estándar, que no puede ser una terminal. Un archivo al que se redirige queda legible solo por su propietario.

Advertencia: El archivo comprimido contiene todos los secretos del appliance. Un FLEETDB_SECRET_KEYS o un FILE_CRED_KEY perdidos no se pueden recuperar de ninguna otra forma. Cifra el archivo comprimido y guárdalo con las copias de seguridad de los volúmenes.

No están en el archivo comprimido: el certificado TLS y su clave (uno generado se vuelve a firmar con la CA), la configuración de Kratos, los archivos del release y los volúmenes de Docker. De certs/ca y registry-token-certs toma los archivos que crea allí una instalación (rootCA.crt, rootCA.key, rootCA.srl; token_private.key, token_public.crt, token_public.der, también con .prev o .new). Cualquier otro archivo de allí se omite, con una advertencia que lo nombra, ya que restore no acepta ningún otro.

# Escribir el archivo comprimido en un archivo que solo root puede leer
sudo ironflock appliance backup -o /root/appliance-secrets.tar.gz
# Escribirlo en la salida estándar, redirigida a un archivo
sudo ironflock appliance backup > appliance-secrets.tar.gz

ironflock appliance restore

Restaura en el directorio de instalación una copia de seguridad que escribió appliance backup.

ironflock appliance restore <file> [flags]

Se ejecuta en: Linux. Root: necesario.

El comando toma los archivos que contiene una copia de seguridad y nada más, cada uno con el propietario y el modo que le da una instalación. En certs/ca y registry-token-certs solo toma los archivos que crea allí una instalación. Un archivo comprimido que contiene algo más se rechaza antes de que cambie nada, y el error indica qué.

Los secretos de un appliance instalado solo se reemplazan con --force; su .env se conserva como .env.prev. Sin --force, la restauración sobre un appliance instalado se rechaza antes de cualquier cambio, con el código de salida 3, y el mensaje indica la restauración con --force y después appliance restart.

Una clave de licencia de la copia de seguridad que no es una clave de licencia válida se restaura tal cual, con una advertencia: todos los comandos del appliance la ignoran.

Contraseñas de la base de datos

• Mientras la base de datos del appliance está en marcha, sus roles toman de inmediato las contraseñas restauradas. Reinicia entonces el appliance (appliance restart), para que todos los servicios lean los archivos restaurados.
• Mientras el appliance no está en marcha, sus roles de la base de datos conservan las contraseñas de antes. La restauración los marca (<install-dir>/.db-roles-pending; roles_pending con --json). El siguiente inicio les asigna las del .env restaurado: appliance start o restart, el arranque del sistema, una instalación o una actualización.

# Restaurar sobre un appliance instalado, y después reiniciarlo
sudo ironflock appliance restore appliance-secrets.tar.gz --force
sudo ironflock appliance restart

Se niega con el código de salida 3 mientras una actualización ha quedado a medias (Cuando una actualización quedó a medias).

ironflock appliance rotate

Da un nuevo valor a un secreto del appliance. El nuevo valor va donde se guarda el anterior (un rol de la base de datos, el archivo de dispositivo del agente, el par de claves de los tokens del registro) y a .env. Después solo se recrean los servicios que lo leen, y el comando comprueba que están sanos.

ironflock appliance rotate <name> [flags]

Se ejecuta en: Linux, con un appliance en marcha. Root: necesario. Pregunta: para un secreto que también guarda otra cosa; --yes responde.

El .env anterior al cambio se conserva como .env.prev, legible solo por root. rotation.log enumera cada rotación, nunca un valor.

• Un secreto que también guarda otra cosa (datos, un dispositivo, un token) pregunta antes de su rotación; --yes responde.
• FILE_CRED_KEY necesita una elección para las claves de acceso directo de los clientes. --keep-direct-access: siguen funcionando, para una rotación planificada; termínala más tarde con revoke-direct-access. --revoke-direct-access: dejan de funcionar y se eliminan, tras una sospecha de filtración.
• APPLIANCE_ADMIN_PASSWORD es lo mismo que reset-admin-password.

Los secretos que rota:

POSTGRES_PASSWORD, PGPASSWORD_KRATOS, PGPASSWORD_ACCT_MANAGER,
PGPASSWORD_ACCT_PUSHER, PGPASSWORD_EXT_ACCT_USER, PGPASSWORD_AUDIT_SANDBOX,
DATASERVICE_PASSWORD, WAMP_SYSTEM_SECRET, WAMP_SECRET_SVC_VDM,
WAMP_SECRET_SVC_IDE, WAMP_SECRET_SVC_IDE_PROXY, WAMP_SECRET_SVC_GIT,
WAMP_SECRET_SVC_REGISTRY, WAMP_SECRET_SVC_REGISTRY_PROXY,
WAMP_SECRET_SVC_ACCT, WAMP_SECRET_SVC_ACCT_PUSH, WAMP_SECRET_SVC_PAYMENT,
WAMP_SECRET_SVC_FLEETDB, WAMP_SECRET_SVC_FLEETFILES, WAMP_SECRET_SVC_AI,
WAMP_SECRET_SVC_TUNNEL, WAMP_SECRET_SVC_RENDERER, WAMP_SECRET_SVC_WEBSERVER,
WAMP_SECRET_SVC_REAPI, WAMP_SECRET_SVC_AUTH, RENDER_TICKET_KEY,
FILES_FORWARD_SECRET, KRATOS_WEBHOOK_SECRET, KRATOS_SECRETS_PAGINATION,
REGISTRY_HTTP_SECRET, TUNNEL_DASHBOARD_PASSWORD, EDGE_SESSION_SECRET,
OBJECTSTORE_ADMIN_ACCESS_KEY, OBJECTSTORE_ADMIN_SECRET_KEY, FILE_CRED_KEY,
FLEETDB_SECRET_KEYS, KRATOS_SECRETS_COOKIE, KRATOS_SECRETS_CIPHER,
APPLIANCE_DEVICE_SECRET, APPLIANCE_ADMIN_PASSWORD, REGISTRY_TOKEN_KEY

Qué hace una rotación con cada tipo de secreto, y qué secretos rotar solo junto con el equipo de IronFlock, se describe en Rotación de un secreto interno.

# Rotar el secreto de un servicio
sudo ironflock appliance rotate WAMP_SECRET_SVC_AI
# Rotar la clave de archivos de forma planificada; las claves de acceso directo siguen funcionando
sudo ironflock appliance rotate FILE_CRED_KEY --keep-direct-access --yes

Se niega con el código de salida 3 mientras una actualización ha quedado a medias (Cuando una actualización quedó a medias).

ironflock appliance revoke-direct-access

Termina una rotación de FILE_CRED_KEY hecha con --keep-direct-access. Todas las claves de acceso directo de los clientes que no se crearon con el FILE_CRED_KEY actual dejan de funcionar y se eliminan; la clave en sí se conserva. El servicio fleetfiles se recrea e informa de lo que eliminó.

ironflock appliance revoke-direct-access [flags]

Se ejecuta en: Linux, con un appliance instalado. Root: necesario. Pregunta: sí, ya que los propietarios de esas claves tienen que crear otras nuevas; --yes responde.

sudo ironflock appliance revoke-direct-access

Se niega con el código de salida 3 mientras una actualización ha quedado a medias (Cuando una actualización quedó a medias).

ironflock appliance remove

Elimina el appliance de IronFlock de esta máquina y deshace lo que su instalación registró en el host. Sus datos se conservan salvo que indiques --purge.

ironflock appliance remove [flags]

Se ejecuta en: Linux. Root: necesario. Pregunta: sí, después de enumerar lo que desaparece y lo que se conserva. La pregunta tiene preseleccionado «No»: Enter solo no elimina nada.

Elimina:

• las unidades systemd del appliance, sus contenedores y su red en Docker;
• el inicio de sesión de Docker en el registro de IronFlock;
• todos los cambios que su instalación registró en el host (/etc/ironflock/appliance.json): la configuración de proxy que escribió, sus ajustes en el daemon.json de Docker, los ajustes del journal y los targets de suspensión enmascarados;
• la copia del release anterior que conservó una actualización para su reversión (.update-previous en el directorio de instalación).

Los volúmenes anónimos de los contenedores del appliance también se eliminan, con o sin --purge: nunca un volumen con nombre, y nunca uno que todavía usa un contenedor.

Qué se conserva

Sin --purge, los datos del appliance se conservan, para que una instalación posterior los recupere:

• el directorio de instalación (/opt/ironflock) con .env, que contiene los secretos, license.env, el registro de las elecciones de la instalación (install.json) y la marca de las contraseñas de la base de datos que una restauración no pudo asignar (.db-roles-pending);
• los volúmenes en Docker.

--purge elimina también estos, y las imágenes: lo que contenía el appliance desaparece para siempre.

Esto se conserva también con --purge:

• Docker en sí, y el agente del dispositivo del host. ironflock agent remove elimina el agente.
• Un archivo que escribió el appliance y que se cambió después, como la configuración de proxy que definió ironflock agent configure, con los drop-ins que la nombran, para que el agente conserve su proxy.
• Lo que el registro del agente (/opt/ironflock/device-init/installed.json) indica como del agente, y los targets de suspensión que enmascaró el agente. ironflock agent remove los elimina.

Cuando falla una llamada

Cuando una llamada de la reversión sigue fallando (por ejemplo, un reinicio de un Docker que se eliminó a mano), el registro se conserva. El comando indica qué llamada falló y termina con un error. Ejecútalo de nuevo cuando eso funcione, o con --force, que descarta el registro de todos modos y continúa tras una unidad que no se puede deshabilitar o un Docker que no responde.

Mientras se ejecuta una instalación, una actualización u otro cambio del appliance, el comando espera hasta 30 segundos y lo indica. Si esa ejecución sigue, no cambia nada y termina con el código de salida 3.

Ejemplos

# Eliminar el appliance y conservar sus datos; el comando enumera lo que desaparece y pregunta
sudo ironflock appliance remove
# Eliminar el appliance con todos sus datos, sin pregunta
sudo ironflock appliance remove --purge --yes

La respuesta no, o una pregunta sin terminal y sin --yes, termina el comando con el código de salida 4.

Antes de eliminar un appliance para siempre, traslada o libera su licencia mientras siga en línea (Retirada del servicio).