CLI

Olivares AI est livré comme un seul binaire Go statique, olivares. Le même artefact est le moteur, la console web embarquée (servie sur la même origine que l’API), et le collecteur edge — le rôle que vous obtenez est choisi par la sous-commande que vous exécutez. Il n’y a pas de téléchargement « serveur » et « agent » séparés.

Cette page documente les commandes et flags confirmés dans le binaire actuel. Elle n’est pas exhaustive, et la surface est pré-1.0 : les sous-commandes, flags et défauts peuvent changer. En cas de doute, exécutez olivares <command> --help contre le build exact que vous avez déployé et considérez cela comme faisant autorité. Pour savoir comment obtenir et exécuter le binaire, voir Auto-hébergement ; pour les paramètres qui vivent dans l’environnement plutôt que dans les flags, voir Configuration.

Aperçu des commandes

olivares <command> [flags]

Le groupe de commandes racine comprend, entre autres :

Les sections ci-dessous couvrent les commandes que les opérateurs utilisent en premier. keys, license et evals sont réels mais spécialisés ; exécutez-les avec --help pour leurs surfaces de flags.

olivares serve

Lance le plan de contrôle : le serveur HTTP (API REST plus la console embarquée) et le serveur gRPC. Trois propriétés sont des défauts, pas des opt-ins :

• TLS est activé par défaut. Sans certificat fourni, le moteur génère un certificat auto-signé dans le répertoire de données et journalise son empreinte SHA-256 ; les clients doivent lui faire confiance ou l’épingler. Le serveur gRPC échoue en fermé — hors --insecure, il refuse de démarrer en texte clair plutôt que de dégrader silencieusement.
• Loopback par défaut. Les deux écouteurs se lient à 127.0.0.1. Exposer le plan de contrôle au-delà de l’hôte local est un changement délibéré : vous définissez une liaison non-loopback et le placez derrière votre propre ingress. Le plan de contrôle fonctionne dans votre infrastructure et peut être air-gappé.
• Aucun identifiant par défaut. Sur une installation neuve sans utilisateurs, le moteur génère un token de configuration unique à usage unique (préfixe olst_) et l’affiche sur stdout uniquement (jamais les logs). Vous bootstrappez le premier administrateur en postant ce token à POST /v1/setup, puis vous vous connectez.

olivares serve
# Lisez le token de configuration olst_ à usage unique depuis le stdout de ce processus.

Flags utiles

SQLite (pure-Go, nœud unique) convient aux installations air-gappées à nœud unique. Sélectionner postgres est ce que vous faites pour les déploiements multi-tenants ou scale-out, où la sécurité au niveau des lignes est le backstop tenant. Il y a d’autres flags pour la résidence et les rôles Postgres (--admin-dsn, --region, --known-regions, --allow-privileged-db-role) — consultez leur --help et la Configuration.

--insecure sert du HTTP et gRPC en texte clair, les tokens bearer circulent donc en clair. Ne l’utilisez jamais sur une adresse accessible au-delà de l’hôte local.

--seed-demo est réservé à la démo

--seed-demo provisionne un environnement synthétique, fabriqué ainsi qu’un administrateur de démonstration dont le mot de passe est public (il vit dans l’arborescence source). Il existe pour que la console et les tests de bout en bout s’affichent contre des données de forme réelle. Parce que l’identifiant est public, serve refuse de démarrer avec --seed-demo sur toute liaison non-loopback et quitte avec une erreur vous dirigeant vers 127.0.0.1.

Traitez-le comme jetable : utilisez un répertoire de données éphémère et ne le pointez jamais vers des données qui vous importent. Une vraie installation est serve sans --seed-demo, où le moteur génère un token de configuration à usage unique et vous créez votre propre administrateur. Voir Démarrage rapide pour le parcours de démo.

olivares collector

Lance le binaire en tant que collecteur edge pour la topologie distribuée. Un collecteur charge les connecteurs source configurés localement et pousse leurs observations vers un core distant via gRPC. Il n’ouvre aucun écouteur entrant — il se connecte vers l’extérieur, il n’accepte pas de connexions, de sorte qu’un collecteur défaillant ne se place jamais dans le chemin de données d’un agent.

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

--core-addr est requis. Le collecteur s’authentifie auprès du core avec un token bearer portant un principal d’ingestion (--token-file, ou $OLIVARES_INGEST_TOKEN) et — quand le core applique le mutual TLS — un certificat client collecteur (--client-cert, --client-key, avec --ca pour épingler un cert core auto-signé). serve et collector câblent leurs connecteurs depuis la même configuration ; une source non configurée prévient honnêtement plutôt que de faire échouer le processus. La configuration des sources est couverte dans Connecter une source.

olivares version

Affiche la version, le commit, la date de build, l’OS/arch et le runtime Go, plus le mode FIPS 140-3 de ce binaire (un mode, pas une déclaration de validation).

olivares version

La chaîne de version est injectée au moment du build ; un build depuis un arbre de travail non tagué rapporte une version de développement. Ne traitez pas la chaîne comme une provenance — vérifiez les releases avec les artefacts signés. Voir Vérifier une release.

olivares openapi

Affiche le document OpenAPI 3.1 du moteur sur stdout, indenté de manière déterministe pour que la sortie se diff proprement, sans serveur en cours d’exécution.

olivares openapi > openapi.json

C’est le même contrat que le moteur sert à GET /openapi.json. La surface REST servie couvre les chemins principaux ; certaines routes de modules sont accessibles mais ne font délibérément pas partie du document servi.

olivares audit et dr

Le registre de preuves a deux groupes de commandes hors ligne :

• audit opère sur le registre append-only : verify la chaîne de hash d’un tenant et ses checkpoints signés, checkpoint pour en écrire un nouveau, export vers un format SIEM (cef/syslog/otlp), et archive export / archive verify pour l’archive immuable qui se re-vérifie hors ligne. audit verify et audit archive verify affichent un rapport JSON et quittent avec 0 par défaut ; passez --strict pour quitter avec un code non nul sur un échec d’intégrité afin que cron ou la CI puisse s’en servir comme contrôle. Les épingles de clé externes (--pubkey, --event-pubkey) remplacent les clés consultatives on-box pour une vérification résistante aux attaquants.
• dr est un backup / restore préservant la continuité du registre, plus verify (un exercice DR non destructif) et inspect. Contrairement à un dump de base de données brut, il capture les clés de signature sous votre clé de chiffrement de clé, enregistre les pointes de chaîne par tenant, et re-vérifie toute la chaîne à la restauration. restore et verify quittent avec un code non nul sauf si le registre restauré est vert.

Ces commandes soutiennent le modèle de vérification décrit dans Gouvernance et Vérifier une release.

Stabilité

Pré-1.0, en développement actif. Les commandes et flags ci-dessus sont confirmés dans le binaire actuel, mais la surface complète évolue encore. Exécutez olivares <command> --help contre votre build et considérez cela comme faisant autorité sur tout document. Pour ce qui est implémenté aujourd’hui versus planifié, voir Transparence et limites.