CLI

Olivares AI wird als ein statisches Go-Binary ausgeliefert, olivares. Dasselbe Artefakt ist die Engine, die eingebettete Webkonsole (auf demselben Origin wie die API bereitgestellt) und der Edge-Kollektor — welche Rolle Sie erhalten, wird durch den Unterbefehl bestimmt, den Sie ausführen. Es gibt keinen separaten “Server”- und “Agent”-Download.

Diese Seite dokumentiert die im aktuellen Binary bestätigten Befehle und Flags. Sie ist nicht vollständig, und die Oberfläche ist pre-1.0: Unterbefehle, Flags und Standards können sich ändern. Im Zweifelsfall führen Sie olivares <command> --help gegen den exakten Build aus, den Sie deployed haben, und behandeln Sie das als autoritativ. Für das Erhalten und Ausführen des Binaries siehe Self-Host; für Einstellungen, die in der Umgebung statt in Flags leben, siehe Konfiguration.

Befehlsübersicht

olivares <command> [flags]

Die Root-Befehlsgruppen, unter anderem:

Die folgenden Abschnitte behandeln die Befehle, nach denen Operatoren am häufigsten greifen. keys, license und evals sind real, aber spezialisiert; führen Sie sie mit --help für ihre Flag-Oberflächen aus.

olivares serve

Führt die Steuerungsebene aus: den HTTP-Server (REST-API plus eingebettete Konsole) und den gRPC-Server. Drei Eigenschaften sind Standards, keine Opt-Ins:

• TLS ist standardmäßig an. Ohne bereitgestelltes Zertifikat generiert die Engine ein selbstsigniertes Zertifikat im Datenverzeichnis und protokolliert dessen SHA-256-Fingerprint; Clients müssen es vertrauen oder pinnen. Der gRPC-Server schließt ablehnend — außerhalb von --insecure weigert er sich, im Klartext zu starten, anstatt stillschweigend zu degradieren.
• Loopback standardmäßig. Beide Listener binden 127.0.0.1. Die Steuerungsebene über den lokalen Host hinaus zu exponieren, ist eine bewusste Änderung: Sie setzen einen Nicht-Loopback-Bind und stellen Ihren eigenen Ingress davor. Die Steuerungsebene läuft in Ihrer Infrastruktur und kann air-gapped sein.
• Keine Standard-Credentials. Bei einer frischen Installation ohne Benutzer prägt die Engine einen einmaligen, einmal verwendbaren Setup-Token (Präfix olst_) und gibt ihn ausschließlich auf stdout aus (nie in die Logs). Sie bootstrappen den ersten Administrator, indem Sie diesen Token an POST /v1/setup senden und sich dann anmelden.

olivares serve
# Lesen Sie den einmaligen olst_-Setup-Token von stdout dieses Prozesses.

Nützliche Flags

SQLite (reines Go, Einzelknoten) eignet sich für air-gapped Einzelknoten-Installationen. Die Auswahl von postgres ist für Multi-Tenant- oder Scale-Out-Deployments, wo Row-Level-Security der Mandanten-Backstop ist. Es gibt weitere Flags für Postgres-Residenz und -Rollen (--admin-dsn, --region, --known-regions, --allow-privileged-db-role) — siehe deren --help und Konfiguration.

--insecure stellt Klartext-HTTP und -gRPC bereit, sodass Bearer-Tokens im Klartext übertragen werden. Verwenden Sie es nie auf einer Adresse, die über den lokalen Host hinaus erreichbar ist.

--seed-demo ist nur für Demos

--seed-demo stellt eine synthetische, fabrizierte Umgebung zusammen mit einem Demo-Administrator bereit, dessen Passwort öffentlich ist (es befindet sich im Quellbaum). Es existiert, damit Konsole und Ende-zu-Ende-Tests gegen live-geformte Daten rendern. Weil das Credential öffentlich ist, weigert sich serve, mit --seed-demo auf einem Nicht-Loopback-Bind zu starten und beendet sich mit einem Fehler, der Sie anweist, 127.0.0.1 zu binden.

Behandeln Sie es als wegwerfbar: Verwenden Sie ein wegwerfbares Datenverzeichnis und richten Sie es nie auf Daten, die Ihnen wichtig sind. Eine echte Installation ist serve ohne --seed-demo, bei der die Engine einen einmaligen Setup-Token prägt und Sie Ihren eigenen Administrator erstellen. Siehe Schnellstart für die Demo-Einführung.

olivares collector

Führt das Binary als Edge-Kollektor für die verteilte Topologie aus. Ein Kollektor lädt die konfigurierten Quellkonnektoren lokal und pusht ihre Beobachtungen an einen entfernten Core über gRPC. Er öffnet keinen eingehenden Listener — er wählt sich raus, akzeptiert keine Verbindungen, sodass ein ausfallender Kollektor nie im Datenpfad eines Agenten sitzt.

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

--core-addr ist erforderlich. Der Kollektor authentifiziert sich beim Core mit einem Bearer-Token, das einen Ingest-Prinzipal hält (--token-file oder $OLIVARES_INGEST_TOKEN) und — wenn der Core gegenseitiges TLS erzwingt — einem Kollektor-Client-Zertifikat (--client-cert, --client-key, mit --ca zum Pinnen eines selbstsignierten Core-Zertifikats). Sowohl serve als auch collector verdrahten ihre Konnektoren aus derselben Konfiguration; eine unkonfigurierte Quelle warnt ehrlich, anstatt den Prozess fehlschlagen zu lassen. Das Konfigurieren von Quellen wird in Eine Quelle verbinden behandelt.

olivares version

Gibt Version, Commit, Build-Datum, OS/Arch und Go-Runtime aus, plus den FIPS-140-3- Modus dieses Binaries (ein Modus, kein Validierungsanspruch).

olivares version

Der Versionsstring wird zur Build-Zeit injiziert; ein Build aus einem ungetaggten Arbeitsbaum meldet eine Entwicklungsversion. Behandeln Sie den String nicht als Provenienz — verifizieren Sie Releases mit den signierten Artefakten. Siehe Einen Release verifizieren.

olivares openapi

Gibt das OpenAPI-3.1-Dokument der Engine auf stdout aus, deterministisch eingerückt, sodass die Ausgabe sauber difft, ohne laufenden Server.

olivares openapi > openapi.json

Das ist derselbe Vertrag, den die Engine unter GET /openapi.json bereitstellt. Die bereitgestellte REST-Oberfläche deckt die Kernpfade ab; einige Modul-Routen sind erreichbar, aber bewusst nicht Teil des bereitgestellten Dokuments.

olivares audit und dr

Das Nachweise-Ledger hat zwei Offline-Befehlsgruppen:

• audit operiert auf dem nur-anhängenden Ledger: verify verifiziert die Hash-Kette eines Mandanten und ihre signierten Checkpoints, checkpoint schreibt einen neuen, export exportiert in ein SIEM-Format (cef/syslog/otlp), und archive export / archive verify für das unveränderliche Archiv, das offline re-verifiziert. audit verify und audit archive verify geben einen JSON-Bericht aus und beenden standardmäßig mit 0; übergeben Sie --strict, um bei fehlgeschlagener Integritätsprüfung mit Nicht-Null zu beenden, sodass Cron oder CI darauf aufbauen können. Externe Schlüssel-Pins (--pubkey, --event-pubkey) ersetzen die On-Box-Advisory-Schlüssel für eine angreifer-resistente Prüfung.
• dr ist ein Ledger-Kontinuitäts-sicheres backup / restore, plus verify (eine nicht-destruktive DR-Übung) und inspect. Anders als ein roher Datenbankdump erfasst es die Signaturschlüssel unter Ihrem Key-Encryption-Key, zeichnet die Pro-Mandant-Chain-Tips auf und re-verifiziert die gesamte Kette beim Restore. restore und verify beenden mit Nicht-Null, es sei denn, das wiederhergestellte Ledger ist grün.

Diese Befehle unterstützen das Verifikationsmodell, das in Governance und Einen Release verifizieren beschrieben wird.

Stabilität

Pre-1.0, in aktiver Entwicklung. Die obigen Befehle und Flags sind im aktuellen Binary bestätigt, aber die vollständige Oberfläche entwickelt sich noch. Führen Sie olivares <command> --help gegen Ihren Build aus und behandeln Sie das als autoritativ gegenüber jedem Dokument. Für das, was heute implementiert ist versus geplant, siehe Ehrlichkeit und Grenzen.