Installer CheatSheet
Quick reference for the commands available in the Anjana Installer command-line interface (CLI), and for the REST endpoints with no CLI equivalent (Preflight, Access Control, Diagnostics, import from the Ansible kit). The CLI connects via HTTPS to the running installer and allows most of the operations available in the graphical interface to be executed.
Tools
List available operations
|
Command |
Description |
|---|---|
|
|
Lists all available tool operations along with their category |
|
|
Shows recent jobs along with their status (PENDING, RUNNING, SUCCESS, FAILED) |
Backup and restore
|
Command |
Description |
|---|---|
|
|
PostgreSQL backup (pg_dump per schema) |
|
|
SeaweedFS/S3 backup (aws s3 sync per bucket) |
|
|
MongoDB backup (mongodump) |
|
|
Configuration backup ( |
|
|
Sequential backup of all persistence stores |
|
|
Restores the latest PostgreSQL backup |
|
|
Restores the latest S3 backup |
|
|
Restores the latest MongoDB backup |
|
|
Restores the latest configuration backup |
|
|
Restores the latest backup of all persistence stores |
Restore from file (no CLI equivalent)
Unlike the rest of the operations in this table, these 5 are not run with tools run <OPERATION> --yes (they have no CLI equivalent): they are triggered by uploading a file to the POST /api/tools/run-with-file endpoint (multipart/form-data, file field). They restore the content of the uploaded file instead of the latest local backup.
|
Operation |
Description |
|---|---|
|
|
Restores PostgreSQL from an uploaded |
|
|
Restores S3/SeaweedFS from an uploaded |
|
|
Restores MongoDB from an uploaded |
|
|
Restores the configuration from an uploaded |
|
|
Restores all persistence stores from an uploaded |
In K8s mode, run-with-file first uploads the file to S3 and launches the job with that reference (runWithFileK8s variant), because K8s jobs run in ephemeral pods with no access to the installer's local filesystem. This variant does not apply to operations in the S3 category, which are always processed directly via the installer's Java SDK.
Data deletion
|
Command |
Description |
|---|---|
|
|
Deletes all PostgreSQL schemas (DROP SCHEMA CASCADE) |
|
|
Deletes all S3 buckets |
|
|
Deletes the MongoDB database |
|
|
Deletes all Solr collections |
|
|
Deletes all OpenSearch indexes |
|
|
Clears the entire Valkey cache (FLUSHALL) |
|
|
Purges all RabbitMQ queues |
|
|
Deletes the local configuration |
Reset and data loading
|
Command |
Description |
|---|---|
|
|
Deletes ALL data from all persistence stores (Empty mode) |
|
|
Deletes everything and loads sample data from the "nativo" dataset |
|
|
Deletes everything and loads sample data for a specific version |
|
|
Deletes everything and restores from the latest local backup |
|
|
Loads sample data without deleting (requires empty persistence stores) |
|
|
Loads development data (requires ROLE_DEV) |
Available datasets: nativo, gob-ext, health-dcatap, pbi. In dev mode: devqa, devqa-config, devqa-grancarga.
This is the static reference list (fallback). Since the introduction of dynamic dataset discovery, the wizard can also show additional datasets published in Nexus (pub-* pattern), retrieved via GET /api/tools/sample-datasets; the static list is only used if that discovery fails or no Nexus credentials are configured.
Export and import (migration between environments)
|
Command |
Description |
|---|---|
|
|
Full backup + packaging into a downloadable .tar.gz |
|
|
Checks TCP connectivity to all persistence stores |
Advanced destructive operations
|
Command |
Description |
|---|---|
|
|
Stops, uninstalls, and removes all local persistence services |
|
|
Complete uninstallation of Anjana (backup + full removal) |
|
|
Unlocks schemas with Liquibase locks (PostgreSQL) |
Logs
|
Command |
Description |
|---|---|
|
|
Last 100 lines of the Horus log |
|
|
Real-time follow of the Horus log |
|
|
Last 500 lines of the PostgreSQL log |
|
|
Last 200 lines + real-time follow |
Console access control (break-glass)
Emergency command for the IP restriction of the installer console itself (the "Restrict access to this console" feature, enabled by default on VM since task DS-133). It acts directly on the data directory on disk, without going through the HTTP API - it works even if the operator themselves is blocked by the whitelist.
|
Command |
Description |
|---|---|
|
|
Creates the break-glass flag: the IP restriction is bypassed immediately (picked up live, ~2 seconds) |
|
|
Removes the flag: the restriction is applied again (re-arms protection) |
|
|
Shows the status of the flag and the persisted configuration (enabled/seeded, pending unconfirmed changes) |
Requires write access to the installer's data directory (root in a standard installation) - that host-level privilege IS the break-glass authorization. Each use is audited in logs/audit.log. Use the --data-dir <path> option to specify a data directory other than the default (/opt/anjana-installer/data).
Not applicable in K8s mode: the console is reached through the ingress/load balancer, whose IP replaces the real client's IP, so the IP restriction does not apply there at all - restrict at the ingress/load balancer or VPN level in that mode.
REST API (no CLI equivalent)
Preflight, Access Control, Diagnostics, and import from the Ansible kit are managed from the graphical interface and have no subcommand in the CLI; they are documented here as a reference for their endpoints.
Preflight
Mandatory pre-validation before Install/Platform Setup: it blocks deployment if any check is in FAIL, if there are unconfirmed WARN checks, or if the report has expired (15-minute TTL by default, configurable) or the configuration has changed since the last run.
|
Method and path |
Description |
|---|---|
|
|
Starts running all preflight checks |
|
|
Returns the latest report (404 if none has been run yet) |
|
|
Details of a preflight or remediation job (status + logs) |
|
|
Live logs of a preflight or remediation job |
|
|
Applies the automatic fix for a remediable check ( |
Access Control
Manages the IP/CIDR whitelist for the nginx front end (general whitelist, internal surfaces, trusted proxies, extra ranges). PUT validates and saves the full configuration block without applying it; apply renders and activates the files with an nginx reload and automatic rollback if it fails.
|
Method and path |
Description |
|---|---|
|
|
Current configuration + status (deployed/applied) + detected client IP |
|
|
Validates and saves the full configuration block (does not apply it) |
|
|
Renders, activates, and reloads nginx ( |
Files on the host (under /<install_folder>/data/config/anjana-ui/):
|
File |
Content |
|---|---|
|
|
Main front-end configuration; includes the following three files |
|
|
Trusted proxies ( |
|
|
General whitelist (restricts all of port 443 if enabled) |
|
|
Whitelist of internal surfaces ( |
During apply, each file is first written as .new, the previous one is backed up as .bak, and it is only replaced if nginx -t validates successfully; if validation fails, the .bak files are restored automatically.
Diagnostics (Export)
Downloads a plain-text diagnostic package for support (job log, latest Preflight report, health snapshot, version inventory, environment summary), redacted of credentials.
|
Method and path |
Description |
|---|---|
|
|
Diagnostic package for the latest deployment job |
|
|
Diagnostic package scoped to a specific job (deployment or tools) |
Settings
|
Method and path |
Description |
|---|---|
|
|
Returns the configured expiration of the admin password (in days) and whether it has expired |
|
|
Updates the admin password expiration (1-3650 days) |
Usage notes
-
The
--yesflag skips interactive confirmation, needed for scripting and automation -
Parameters are passed with
--param key=value; multiple--paramcan be chained -
Destructive operations require an explicit
--yes; without it, keyboard confirmation is requested -
Service names in logs use hyphens (e.g.:
tot-plugin-jdbc,anjana-ui) -
The CLI requires the installer to be running (it connects via HTTPS on port 8787)
Equivalence with the Ansible kit
To facilitate the transition from the Ansible kit, the following table shows the mapping between the commands from the previous kit and the new installer commands:
|
Ansible kit |
Anjana Installer |
|---|---|
|
|
Full Install from the UI |
|
|
|
|
|
Platform Setup from the UI |
|
|
Start Services from the UI |
|
|
Stop Services from the UI |
|
|
Restart Services from the UI |
|
|
Upgrade Product from the UI |
|
|
Update Service Units from the UI |
|
|
Update Service Units from the UI |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Import Data from the UI (requires file upload) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Automatic configuration migration
In addition to the command-to-command equivalence, the installer can directly import the Ansible kit's configuration files and generate the initial configuration without repeating the process manually:
|
Method and path |
Description |
|---|---|
|
|
Uploads the kit files and returns the mapped configuration + warnings, without saving anything |
|
|
Same as |
The files are uploaded as multipart/form-data: allYaml and hostsYaml (from the Ansible kit) are mandatory; anjanauiYaml (the kit's anjanauihosts.yaml, with the apache/persistence/horus whitelists) is optional and, if included, maps those whitelists to the new Access Control.
Importing your own configuration (installer YAML)
Sibling routes to the previous ones, but for importing a configuration ALREADY exported from the installer itself (not a legacy Ansible kit):
|
Method and path |
Description |
|---|---|
|
|
Uploads the YAML exported by the installer and returns the mapped configuration, without saving anything |
|
|
Same as |
The file is uploaded as multipart/form-data in the configYaml field. The Nexus URL and repository are never imported (they remain fixed); if the secrets store does not have a Nexus password configured, the response warns that the Credentials step still needs to be completed.