CLI

Olivares AI dostarczany jest jako jeden statyczny plik binarny Go, olivares. Ten sam artefakt jest silnikiem, wbudowaną konsolą webową (serwowaną na tym samym origin co API) i kolektorem brzegowym — którą rolę otrzymujesz, wybiera podkomenda, którą uruchamiasz. Nie ma oddzielnego pobierania “serwera” i “agenta”.

Ta strona dokumentuje polecenia i flagi potwierdzone w bieżącym pliku binarnym. Nie jest wyczerpująca, a powierzchnia jest pre-1.0: podkomendy, flagi i domyślne mogą się zmieniać. W razie wątpliwości uruchom olivares <command> --help wobec dokładnej budowy, którą wdrożyłeś, i traktuj to jako autorytatywne. Jak uzyskać i uruchomić plik binarny, zobacz Self-host; dla ustawień, które żyją w środowisku zamiast flag, zobacz Konfiguracja.

Przegląd poleceń

olivares <command> [flags]

Grupy poleceń głównych, między innymi:

Sekcje poniżej obejmują polecenia, po które operatorzy sięgają najczęściej. keys, license i evals są prawdziwe, ale specjalistyczne; uruchom je z --help dla ich powierzchni flag.

olivares serve

Uruchamia płaszczyznę kontrolną: serwer HTTP (REST API plus wbudowana konsola) i serwer gRPC. Trzy właściwości są domyślne, nie opcjonalne:

• TLS jest domyślnie włączony. Bez dostarczonego certyfikatu silnik generuje samopodpisany certyfikat w katalogu danych i loguje jego odcisk SHA-256; klienci muszą mu zaufać lub go przypiąć. Serwer gRPC zamyka się odrzucając — poza --insecure odmawia uruchomienia w plaintext zamiast cicho degradować.
• Loopback domyślnie. Oba listenery wiążą 127.0.0.1. Udostępnianie płaszczyzny kontrolnej poza hostem lokalnym to celowa zmiana: ustawiasz nie-loopbackowy bind i stawiasz przed nim własny ingress. Płaszczyzna kontrolna działa w twojej infrastrukturze i może być izolowana sieciowo.
• Brak domyślnych poświadczeń. Na świeżej instalacji bez użytkowników silnik tworzy jednorazowy, jednorazowego użytku token konfiguracji (prefiks olst_) i drukuje go tylko na stdout (nigdy do logów). Bootstrapujesz pierwszego administratora postując ten token do POST /v1/setup, następnie logujesz się.

olivares serve
# Odczytaj jednorazowy token olst_ ze stdout tego procesu.

Użyteczne flagi

SQLite (czysty Go, jednowęzłowy) nadaje się do izolowanych sieciowo, jednowęzłowych instalacji. Wybranie postgres to co robisz dla wdrożeń wielodzierżawczych lub skalowalnych, gdzie bezpieczeństwo na poziomie wierszy jest zabezpieczeniem dzierżawcy. Są dalsze flagi dla Postgres rezydencji i ról (--admin-dsn, --region, --known-regions, --allow-privileged-db-role) — zobacz ich --help i Konfiguracja.

--insecure serwuje plaintext HTTP i gRPC, więc tokeny bearer podróżują otwartym tekstem. Nigdy nie używaj tego na jakimkolwiek adresie osiągalnym spoza hosta lokalnego.

--seed-demo jest tylko do demo

--seed-demo udostępnia syntetyczną, sfabrykowaną infrastrukturę wraz z demostracyjnym administratorem, którego hasło jest publiczne (żyje w drzewie źródeł). Istnieje, by konsola i testy end-to-end renderowały wobec danych o kształcie produkcyjnym. Ponieważ poświadczenie jest publiczne, serve odmawia uruchomienia z --seed-demo na jakimkolwiek nie-loopbackowym bind i kończy z błędem kierującym do bind 127.0.0.1.

Traktuj go jako jednorazowy: użyj jednorazowego katalogu danych i nigdy nie kieruj go na dane, na których ci zależy. Prawdziwa instalacja to serve bez --seed-demo, gdzie silnik tworzy jednorazowy token konfiguracji i tworzysz własnego administratora. Zobacz Szybki start dla przewodnika demo.

olivares collector

Uruchamia plik binarny jako kolektor brzegowy dla rozproszonej topologii. Kolektor ładuje skonfigurowane konektory źródeł lokalnie i wypycha ich obserwacje do zdalnego rdzenia przez gRPC. Nie otwiera żadnego przychodzącego listenera — dzwoni na zewnątrz, nie akceptuje połączeń, więc wadliwy kolektor nigdy nie siedzi na ścieżce danych jakiegokolwiek agenta.

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

--core-addr jest wymagany. Kolektor uwierzytelnia się do rdzenia tokenem bearer zawierającym podmiot ingest (--token-file lub $OLIVARES_INGEST_TOKEN) i — gdy rdzeń wymusza wzajemny TLS — certyfikatem klienckim kolektora (--client-cert, --client-key, z --ca do przypięcia samopodpisanego certyfikatu rdzenia). Zarówno serve jak i collector podłączają swoje konektory z tej samej konfiguracji; nieskonfigurowane źródło ostrzega uczciwie zamiast powodować błąd procesu. Konfiguracja źródeł jest opisana w Podłącz źródło.

olivares version

Drukuje wersję, commit, datę budowy, OS/arch i runtime Go, plus tryb FIPS 140-3 tego pliku binarnego (tryb, nie twierdzenie walidacji).

olivares version

Łańcuch wersji jest wstrzykiwany w czasie budowy; budowa z nieotagowanego drzewa roboczego raportuje wersję deweloperską. Nie traktuj łańcucha jako provenance — weryfikuj wydania podpisanymi artefaktami. Zobacz Weryfikacja wydania.

olivares openapi

Drukuje dokument OpenAPI 3.1 silnika na stdout, deterministycznie wcięty więc wyjście diffuje czysto, bez uruchomionego serwera.

olivares openapi > openapi.json

To ten sam kontrakt, który silnik serwuje na GET /openapi.json. Serwowana powierzchnia REST obejmuje ścieżki rdzeniowe; niektóre trasy modułów są osiągalne, ale celowo nie są częścią serwowanego dokumentu.

olivares audit i dr

Rejestr dowodów ma dwie grupy poleceń offline:

• audit operuje na rejestrze tylko-do-dopisywania: verify łańcuch haszy dzierżawcy i jego podpisane checkpointy, checkpoint by zapisać nowy, export do formatu SIEM (cef/syslog/otlp) i archive export / archive verify dla niezmiennego archiwum, które ponownie weryfikuje offline. audit verify i audit archive verify drukują raport JSON i kończą z kodem 0 domyślnie; przekaż --strict by kończyć z kodem niezerowym na błędzie sprawdzenia integralności, aby cron lub CI mogły bramkować na tym. Zewnętrzne przypięcia kluczy (--pubkey, --event-pubkey) zastępują klucze doradcze na maszynkę dla sprawdzenia odpornego na atakującego.
• dr to kopia zapasowa / przywracanie bezpieczne dla ciągłości rejestru, plus verify (niedestrukcyjne ćwiczenie DR) i inspect. W przeciwieństwie do surowego zrzutu bazy danych przechwytuje klucze podpisu pod twoim kluczem szyfrowania kluczy, rejestruje końcówki łańcucha per-dzierżawca i ponownie weryfikuje cały łańcuch przy przywracaniu. restore i verify kończą z kodem niezerowym chyba że przywrócony rejestr jest poprawny.

Te polecenia wspierają model weryfikacji opisany w Zarządzanie i Weryfikacja wydania.

Stabilność

Pre-1.0, w aktywnym rozwoju. Polecenia i flagi powyżej są potwierdzone w bieżącym pliku binarnym, ale pełna powierzchnia nadal ewoluuje. Uruchom olivares <command> --help wobec swojej budowy i traktuj to jako autorytatywne nad jakimkolwiek dokumentem. Co jest zaimplementowane dzisiaj vs planowane, zobacz Uczciwości i ograniczenia.