CLI

La CLI olivares — i comandi top-level verificati del singolo binario self-hostabile e i flag di serve sicuri per default, incluso --seed-demo

Olivares AI viene distribuito come un singolo binario Go statico, olivares. Lo stesso artefatto è il motore, la console web incorporata (servita sulla stessa origine dell’API) e il collector edge — quale ruolo ottieni e scelto dal sottocomando che esegui. Non c’e un download separato per “server” e “agent”.

Questa pagina documenta i comandi e i flag confermati nel binario attuale. Non e esaustiva, e la superficie e pre-1.0: sottocomandi, flag e default possono cambiare. In caso di dubbio, esegui olivares <command> --help sulla build esatta che hai distribuito e trattala come autorevole. Per come ottenere ed eseguire il binario, vedi Self-host; per le impostazioni che risiedono nell’ambiente anziché nei flag, vedi Configurazione.

Panoramica dei comandi

olivares <command> [flags]

Il comando root raggruppa, tra gli altri:

Le sezioni sotto coprono i comandi che gli operatori usano per primi. keys, license e evals sono reali ma specializzati; eseguili con --help per le loro superfici di flag.

olivares serve

Esegue il piano di controllo: il server HTTP (API REST più la console incorporata) e il server gRPC. Tre proprietà sono default, non opt-in:

TLS è attivo per default. Senza certificato fornito, il motore genera un certificato self-signed nella directory dati e registra la sua impronta SHA-256; i client devono fidarsi o fissarla. Il server gRPC fallisce chiuso — al di fuori di --insecure rifiuta di avviarsi in testo chiaro anziché degradare silenziosamente.
Loopback per default. Entrambi i listener si collegano a 127.0.0.1. Esporre il piano di controllo oltre l’host locale e un cambiamento deliberato: imposti un bind non-loopback e lo fronti con il tuo ingress. Il piano di controllo gira nella tua infrastruttura e può essere air-gapped.
Nessuna credenziale predefinita. Su un’installazione nuova senza utenti, il motore genera un token di setup unico e monouso (prefisso olst_) e lo stampa solo su stdout (mai nei log). Fai il bootstrap del primo amministratore inviando quel token a POST /v1/setup, poi accedi.

olivares serve
# Read the one-time olst_ setup token from this process's stdout.

Flag utili

SQLite (pure-Go, singolo nodo) è adatto per installazioni air-gapped a singolo nodo. Selezionare postgres e ciò che fai per deployment multi-tenant o scale-out, dove la row-level security e il backstop del tenant. Ci sono ulteriori flag per la residenza e i ruoli Postgres (--admin-dsn, --region, --known-regions, --allow-privileged-db-role) — vedi il loro --help e Configurazione.

--insecure serve HTTP e gRPC in testo chiaro, quindi i bearer token viaggiano in chiaro. Non usarlo mai su alcun indirizzo raggiungibile al di fuori dell’host locale.

`--seed-demo` e solo per la demo

--seed-demo configura un estate sintetico, fabbricato insieme a un amministratore demo la cui password è pubblica (risiede nel tree dei sorgenti). Esiste per far rendere la console e i test end-to-end su dati a forma reale. Poiché la credenziale è pubblica, serve rifiuta di avviarsi con --seed-demo su qualsiasi bind non-loopback e esce con un errore che ti indirizza a collegare 127.0.0.1.

Trattalo come usa e getta: usa una directory dati temporanea e non puntarlo mai a dati che ti interessano. Un’installazione reale e serve senza --seed-demo, dove il motore genera un token di setup unico e tu crei il tuo amministratore. Vedi Quickstart per la guida alla demo.

olivares collector

Esegue il binario come collector edge per la topologia distribuita. Un collector carica i connettori sorgente configurati localmente e invia le loro osservazioni a un core remoto tramite gRPC. Non apre nessun listener in ingresso — chiama fuori, non accetta connessioni, quindi un collector che fallisce non si interpone mai nel percorso dati di alcun agente.

olivares collector --core-addr host:port [flags]

--core-addr e obbligatorio. Il collector si autentica al core con un bearer token che porta un principal di ingestione (--token-file, o $OLIVARES_INGEST_TOKEN) e — quando il core applica mutual TLS — un certificato client del collector (--client-cert, --client-key, con --ca per fissare un certificato core self-signed). Sia serve che collector cablano i loro connettori dalla stessa configurazione; una sorgente non configurata avvisa onestamente anziché far fallire il processo. La configurazione delle sorgenti è coperta in Collegare una sorgente.

olivares version

Stampa la versione, il commit, la data di build, OS/arch e il runtime Go, più la modalità FIPS 140-3 di questo binario (una modalità, non una dichiarazione di validazione).

olivares version

La stringa di versione viene iniettata al momento della build; una build da un working tree non taggato riporta una versione di sviluppo. Non trattare la stringa come provenienza — verifica i rilasci con gli artefatti firmati. Vedi Verificare un rilascio.

olivares openapi

Stampa il documento OpenAPI 3.1 del motore su stdout, indentato deterministicamente in modo che l’output si confronti pulitamente, senza un server in esecuzione.

olivares openapi > openapi.json

Questo è lo stesso contratto che il motore serve a GET /openapi.json. La superficie REST servita copre i percorsi principali; alcune rotte dei moduli sono raggiungibili ma deliberatamente non parte del documento servito.

olivares audit e dr

Il registro delle evidenze ha due gruppi di comandi offline:

audit opera sul registro append-only: verify la catena hash di un tenant e i suoi checkpoint firmati, checkpoint per scriverne uno nuovo, export in un formato SIEM (cef/syslog/otlp), e archive export / archive verify per l’archivio immutabile che si ri-verifica offline. audit verify e audit archive verify stampano un report JSON e escono con 0 per default; passa --strict per uscire con non-zero su un controllo di integrità fallito cosi cron o CI possono bloccarlo. Pin di chiavi esterne (--pubkey, --event-pubkey) sostituiscono le chiavi advisory on-box per un controllo resistente agli attaccanti.
dr e un backup / restore sicuro per la continuità del registro, più verify (un’esercitazione DR non distruttiva) e inspect. A differenza di un dump raw del database cattura le chiavi di firma sotto la tua chiave di crittografia delle chiavi, registra i tip della catena per tenant, e ri-verifica l’intera catena al ripristino. restore e verify escono con non-zero a meno che il registro ripristinato non sia verde.

Questi comandi supportano il modello di verifica descritto in Governance e Verificare un rilascio.

Stabilità

Pre-1.0, in sviluppo attivo. I comandi e i flag sopra sono confermati nel binario attuale, ma la superficie completa e ancora in evoluzione. Esegui olivares <command> --help sulla tua build e trattala come autorevole rispetto a qualsiasi documento. Per ciò che è implementato oggi rispetto a quanto pianificato, vedi Trasparenza e limiti.