CheatSheets Installer | Anjana Data Documentación

CheatSheet del Instalador

Referencia rápida de los comandos disponibles en la interfaz de línea de comandos (CLI) del Anjana Installer, y de los endpoints REST sin equivalente en CLI (Preflight, Control de Acceso, Diagnósticos, importación desde el kit Ansible). La CLI se conecta vía HTTPS al instalador en ejecución y permite ejecutar la mayoría de las operaciones disponibles en la interfaz gráfica.

Herramientas (Tools)

Listar operaciones disponibles

Comando	Descripción
`tools list`	Lista todas las operaciones de herramientas disponibles con su categoría
`tools jobs`	Muestra los jobs recientes con su estado (PENDING, RUNNING, SUCCESS, FAILED)

Backup y restauración

Comando	Descripción
`tools run BACKUP_POSTGRESQL --yes`	Backup de PostgreSQL (pg_dump por schema)
`tools run BACKUP_S3 --yes`	Backup de SeaweedFS/S3 (aws s3 sync por bucket)
`tools run BACKUP_MONGODB --yes`	Backup de MongoDB (mongodump)
`tools run BACKUP_CONFIG --yes`	Backup de configuración (`/{installFolder}/data/config`)
`tools run BACKUP_ALL --yes`	Backup de todas las persistencias secuencialmente
`tools run RESTORE_POSTGRESQL --yes`	Restaura último backup de PostgreSQL
`tools run RESTORE_S3 --yes`	Restaura último backup de S3
`tools run RESTORE_MONGODB --yes`	Restaura último backup de MongoDB
`tools run RESTORE_CONFIG --yes`	Restaura último backup de configuración
`tools run RESTORE_ALL --yes`	Restaura último backup de todas las persistencias

Restauración desde fichero (sin equivalente CLI)

A diferencia del resto de operaciones de esta tabla, estas 5 no se ejecutan con tools run <OPERACIÓN> --yes (no tienen equivalente en la CLI): se lanzan subiendo un fichero al endpoint POST /api/tools/run-with-file (multipart/form-data, campo file). Restauran el contenido del fichero subido en vez del último backup local.

Operación	Descripción
`RESTORE_POSTGRESQL_FILE`	Restaura PostgreSQL desde un fichero `.sql` subido, en vez del último backup local
`RESTORE_S3_FILE`	Restaura S3/SeaweedFS desde un fichero `.tgz` subido, en vez del último backup local
`RESTORE_MONGODB_FILE`	Restaura MongoDB desde un fichero `.tar.gz` subido, en vez del último backup local
`RESTORE_CONFIG_FILE`	Restaura la configuración desde un fichero `.tar.gz` subido, en vez del último backup local
`IMPORT_DATA`	Restaura todas las persistencias desde un paquete `.tar.gz` subido (el mismo formato que genera `EXPORT_DATA`), en vez del último backup local

En modo K8s, run-with-file sube antes el fichero a S3 y lanza el job con esa referencia (variante runWithFileK8s), porque los jobs de K8s corren en pods efímeros sin acceso al filesystem local del instalador. Esta variante no aplica a operaciones de la categoría S3, que siempre se procesan directamente vía el SDK de Java del instalador.

Borrado de datos

Comando	Descripción
`tools run DELETE_POSTGRESQL --yes`	Borra todos los schemas de PostgreSQL (DROP SCHEMA CASCADE)
`tools run DELETE_S3 --yes`	Borra todos los buckets de S3
`tools run DELETE_MONGODB --yes`	Borra la base de datos de MongoDB
`tools run DELETE_SOLR_COLLECTIONS --yes`	Borra todas las colecciones de Solr
`tools run DELETE_OPENSEARCH_INDEXES --yes`	Borra todos los índices de OpenSearch
`tools run FLUSH_VALKEY --yes`	Limpia toda la caché de Valkey (FLUSHALL)
`tools run PURGE_RABBITMQ --yes`	Purga todas las colas de RabbitMQ
`tools run DELETE_CONFIG --yes`	Borra la configuración local

Reset y carga de datos

Comando	Descripción
`tools run RESET_ALL --yes`	Borra TODOS los datos de todas las persistencias (modo Empty)
`tools run RESET_ALL --param restore=sample --param dataset=nativo --yes`	Borra todo y carga datos de ejemplo del dataset "nativo"
`tools run RESET_ALL --param restore=sample --param dataset=nativo --param version=26.1 --yes`	Borra todo y carga datos de ejemplo de una versión específica
`tools run RESET_ALL --param restore=backup --yes`	Borra todo y restaura desde el último backup local
`tools run LOAD_SAMPLE_DATA --param dataset=nativo --yes`	Carga datos de ejemplo sin borrar (requiere persistencias vacías)
`tools run LOAD_SAMPLE_DATA --param dataset=devqa --param devMode=true --yes`	Carga datos de desarrollo (requiere ROLE_DEV)

Datasets disponibles: nativo, gob-ext, health-dcatap, pbi. En modo dev: devqa, devqa-config, devqa-grancarga.

Esta es la lista estática de referencia (fallback). Desde la introducción del descubrimiento dinámico de datasets, el wizard puede mostrar además datasets adicionales publicados en Nexus (patrón pub-*), consultados vía GET /api/tools/sample-datasets; la lista estática solo se usa si ese descubrimiento falla o no hay credenciales de Nexus configuradas.

Exportación e importación (migración entre entornos)

Comando	Descripción
`tools run EXPORT_DATA --yes`	Backup completo + empaquetado en .tar.gz descargable
`tools run CONNECTION_CHECK --yes`	Verifica conectividad TCP a todas las persistencias

Operaciones destructivas avanzadas

Comando	Descripción
`tools run PURGE_PERSISTENCE --yes`	Detiene, desinstala y elimina todos los servicios de persistencia locales
`tools run UNINSTALL_PLATFORM --yes`	Desinstalación completa de Anjana (backup + eliminación total)
`tools run UNLOCK_SCHEMAS --yes`	Desbloquea schemas con locks de Liquibase (PostgreSQL)

Logs

Comando	Descripción
`logs horus --lines 100`	Últimas 100 líneas del log de Horus
`logs horus --follow`	Seguimiento en tiempo real del log de Horus
`logs postgresql --lines 500`	Últimas 500 líneas del log de PostgreSQL
`logs tot-plugin-jdbc --follow --lines 200`	Últimas 200 líneas + seguimiento en tiempo real

Control de acceso a la consola (break-glass)

Comando de emergencia para la restricción de IP de la propia consola del instalador (feature "Restrict access to this console", activada por defecto en VM desde la tarea DS-133). Actúa directamente sobre el directorio de datos en disco, sin pasar por la API HTTP - funciona incluso si el propio operador está bloqueado por la whitelist.

Comando	Descripción
`access disable`	Crea el flag de break-glass: la restricción de IP queda bypaseada de inmediato (se recoge en caliente, ~2 segundos)
`access enable`	Elimina el flag: la restricción vuelve a aplicarse (rearma la protección)
`access status`	Muestra el estado del flag y de la configuración persistida (enabled/seeded, cambios pendientes sin confirmar)

Requiere acceso de escritura al directorio de datos del instalador (root en una instalación estándar) - ese privilegio a nivel de host ES la autorización del break-glass. Cada uso queda auditado en logs/audit.log. Opción --data-dir <ruta> para indicar un directorio de datos distinto del por defecto (/opt/anjana-installer/data).

No aplicable en modo K8s: la consola se alcanza a través del ingress/load balancer, cuya IP sustituye a la del cliente real, así que la restricción de IP no se aplica ahí en absoluto - restringir a nivel de ingress/load balancer o VPN en ese modo.

API REST (sin equivalente en CLI)

Preflight, Control de Acceso, Diagnósticos e importación desde el kit Ansible se gestionan desde la interfaz gráfica y no tienen subcomando en la CLI; se documentan aquí como referencia de sus endpoints.

Preflight

Validación previa obligatoria antes de Install/Platform Setup: bloquea el despliegue si algún check está en FAIL, si hay checks en WARN sin confirmar, o si el informe caducó (TTL de 15 minutos por defecto, configurable) o la configuración cambió desde la última ejecución.

Método y ruta	Descripción
`POST /api/preflight`	Inicia la ejecución de todos los checks de preflight
`GET /api/preflight/latest`	Devuelve el último informe (404 si aún no se ha ejecutado ninguno)
`GET /api/preflight/{jobId}`	Detalle de un job de preflight o remediación (estado + logs)
`GET /api/preflight/{jobId}/logs`	Logs en vivo de un job de preflight o remediación
`POST /api/preflight/{checkId}/remediate?host=X`	Aplica la corrección automática de un check remediable (`host` es opcional; se omite en checks globales)

Control de acceso (Access Control)

Gestiona la whitelist de IPs/CIDR del frontal nginx (whitelist general, superficies internas, proxies de confianza, rangos extra). PUT valida y guarda el bloque completo sin aplicarlo; apply renderiza y activa los ficheros con recarga de nginx y rollback automático si falla.

Método y ruta	Descripción
`GET /api/security/access-control`	Configuración actual + estado (desplegado/aplicado) + IP del cliente detectada
`PUT /api/security/access-control`	Valida y guarda el bloque completo de configuración (no lo aplica)
`POST /api/security/access-control/apply`	Renderiza, activa y recarga nginx (`nginx -t` + rollback automático si falla)

Ficheros en el host (bajo /<install_folder>/data/config/anjana-ui/):

Fichero	Contenido
`nginx.conf`	Configuración principal del frontal; incluye los tres ficheros siguientes
`realip.conf`	Proxies de confianza (`set_real_ip_from` + `real_ip_header`)
`whitelist-general.conf`	Whitelist general (restringe todo el puerto 443 si está activada)
`whitelist-internal.conf`	Whitelist de superficies internas (`/solr`, `/s3`, `/horus/*`)

Durante apply, cada fichero se escribe primero como .new, se respalda el anterior como .bak, y se sustituye solo si nginx -t valida correctamente; si la validación falla, los .bak se restauran automáticamente.

Diagnósticos (Export)

Descarga un paquete de diagnóstico en texto plano para soporte (log de job, último informe de Preflight, foto de salud, inventario de versiones, resumen de entorno), redactado de credenciales.

Método y ruta	Descripción
`GET /api/diagnostics/export`	Paquete de diagnóstico del último job de despliegue
`GET /api/diagnostics/export?jobId=X`	Paquete de diagnóstico acotado a un job concreto (de despliegue o de herramientas)

Ajustes (Settings)

Método y ruta	Descripción
`GET /api/settings/password-policy`	Devuelve la caducidad configurada de la contraseña de admin (días) y si está expirada
`PUT /api/settings/password-policy`	Actualiza la caducidad de la contraseña de admin (1-3650 días)

Notas de uso

El flag --yes omite la confirmación interactiva, necesario para scripting y automatización
Los parámetros se pasan con --param clave=valor, se pueden encadenar múltiples --param
Las operaciones destructivas requieren --yes explícito; sin él, se solicita confirmación por teclado
Los nombres de servicio en logs usan guiones (ej: tot-plugin-jdbc, anjana-ui)
La CLI requiere que el instalador esté corriendo (se conecta vía HTTPS al puerto 8787)

Equivalencia con kit Ansible

Para facilitar la transición desde el kit Ansible, la siguiente tabla muestra la correspondencia entre los comandos del kit anterior y los nuevos comandos del instalador:

Kit Ansible	Anjana Installer
`anjana`	Full Install desde UI
`anjana -t anjana-sample`	`tools run RESET_ALL --param restore=sample --param dataset=nativo --yes`
`anjana -t platform`	Platform Setup desde UI
`anjana -t start`	Start Services desde UI
`anjana -t stop`	Stop Services desde UI
`anjana -t restart`	Restart Services desde UI
`anjana -t update`	Upgrade Product desde UI
`anjana -t update-config`	Update Service Units desde UI
`anjana -t update-services`	Update Service Units desde UI
`anjana -t backup`	`tools run BACKUP_ALL --yes`
`anjana -t backup-persistences`	`tools run BACKUP_ALL --yes`
`anjana -t backup-config`	`tools run BACKUP_CONFIG --yes`
`anjana -t restore`	`tools run RESTORE_ALL --yes`
`anjana -t restore-s3`	`tools run RESTORE_S3 --yes`
`anjana -t restore-bbdd`	`tools run RESTORE_POSTGRESQL --yes`
`anjana -t restore-config`	`tools run RESTORE_CONFIG --yes`
`anjana -t export`	`tools run EXPORT_DATA --yes`
`anjana -t import`	Import Data desde UI (requiere upload de fichero)
`anjana -t delete`	`tools run RESET_ALL --yes`
`anjana -t insert`	`tools run LOAD_SAMPLE_DATA --param dataset=nativo --yes`
`anjana -t reset`	`tools run RESET_ALL --param restore=sample --param dataset=nativo --yes`
`anjana -t export-log`	`logs <servicio> --lines 5000`
`anjana -t uninstall`	`tools run UNINSTALL_PLATFORM --yes`

Migración automática de configuración

Además de la equivalencia comando a comando, el instalador puede importar directamente los ficheros de configuración del kit Ansible y generar la configuración inicial sin repetir el proceso manualmente:

Método y ruta	Descripción
`POST /api/import/ansible/preview`	Sube los ficheros del kit y devuelve la configuración mapeada + avisos, sin guardar nada
`POST /api/import/ansible/confirm`	Igual que `preview`, pero persiste la configuración y las credenciales detectadas

Los ficheros se suben como multipart/form-data: allYaml y hostsYaml (del kit Ansible) son obligatorios; anjanauiYaml (el anjanauihosts.yaml del kit, con las whitelists de apache/persistencias/horus) es opcional y, si se incluye, mapea esas whitelists al nuevo Control de Acceso.

Importación de configuración propia (YAML del instalador)

Rutas hermanas de las anteriores, pero para importar una configuración YA exportada del propio instalador (no un kit Ansible legacy):

Método y ruta	Descripción
`POST /api/import/config/preview`	Sube el YAML exportado por el instalador y devuelve la configuración mapeada, sin guardar nada
`POST /api/import/config/confirm`	Igual que `preview`, pero persiste la configuración

El fichero se sube como multipart/form-data en el campo configYaml. La URL y el repositorio de Nexus nunca se importan (se mantienen fijos); si el almacén de secretos no tiene contraseña de Nexus configurada, la respuesta avisa de que falta completar el paso de Credenciales.