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 Unterbefehle, Flags und Standards können sich zwischen Versionen ä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

Die obigen Befehle und Flags entsprechen der aktuellen Version. Führen Sie olivares <command> --help mit Ihrem installierten Binary aus; die Ausgabe ist maßgeblich gegenüber jedem Dokument. Was jedes Modul heute leistet, steht unter Ehrlichkeit und Grenzen.