コンテンツにスキップ
Olivares AI docs

パッケージからインストール

次のリリースは 0.4 で、GitHub ではまだ公開されていません。以下のコマンドは予定されている成果物を示します。公開まではソースからビルドし、公開後も使用前に各成果物を検証してください。観測した公開状況は docs/releases/0.4-install-surfaces.json に記録されています。

これは、エンジンをコンテナではなくサービスとして動かしたい通常の Linux ホスト向けの経路である。 Debian/Ubuntu と RHEL/Fedora/SUSE のデフォルトは systemd である。Alpine のデフォルト init は systemd ではなく OpenRC である。コンテナは Docker でデプロイする を、出口経路のないホストは エアギャップ環境にインストールする を参照。このページは アップグレード手順で後者に戻る。

1. 信頼する前にリリースを検証する

Section titled “1. 信頼する前にリリースを検証する”

セキュリティ製品ではビルドパイプラインが信頼モデルの一部なので、ここではダウンロードを 鵜呑みにするよう求めない。パッケージ、checksums.txt、署名を同じディレクトリに置き、 検証器を そのディレクトリから 実行する。

ターミナルウィンドウ
# The verifier is in a source checkout of the release tag, not a release asset; running it
# trusts the checkout. Without one, INSTALL.md shows the cosign + sha256sum commands.
# keyless / Sigstore (default; reaches Rekor over the network)
/path/to/olivares/scripts/verify-release.sh

リリースはキーレスで署名され、cosign の公開鍵は公開されない。したがって、リリースから ダウンロードしたパッケージにはキーレスのコマンドを使う。これには Sigstore の信頼ルート材料が 必要で、キャッシュ済みでなければ cosign が取得する。--offline は Rekor 照会を除くだけで、 検証がネットワーク不要になるわけではない。--key は自分が管理する秘密鍵で署名されたファイル専用で あり、その公開鍵は検証対象のファイルとは別に入手しなければならない。

各ステップが何を検査するか、部分リリースでの振る舞い、コンテナ画像の検証方法は ダウンロードしたものを検証する にある。

2. パッケージをインストールする

Section titled “2. パッケージをインストールする”

3 つの形式はバイナリ /usr/bin/olivares、環境ファイル /etc/olivares/olivares.env （config|noreplace）、データディレクトリ /var/lib/olivares、ライセンス文書を運ぶ。 .deb/.rpm は硬化した systemd ユニットを同梱する。 .apk は実行可能な OpenRC ユニットを /etc/init.d/olivares に置き、フックがホストの systemctl の有無から推測しないよう明示的な package-init スタンプを添える。Linux アーカイブは 同じサービスアダプタ scripts/install-service.sh と packaging/service/ を運ぶ。

ターミナルウィンドウ
# Debian / Ubuntu
sudo dpkg -i olivares_0.4_linux_amd64.deb


# RHEL / Fedora / SUSE
sudo rpm -Uvh olivares_0.4_linux_amd64.rpm


# Alpine
sudo apk add --allow-untrusted olivares_0.4_linux_amd64.apk

インストールは システムユーザーとグループ olivares を作成する（シェルは /usr/sbin/nologin、ホームは /var/lib/olivares）。/var/lib/olivares をそのユーザー所有の モード 0750 で作成し、/etc/olivares を作成する。systemd パッケージは systemctl が あるとき systemd を再読み込みする。OpenRC パッケージはサービスを有効化も起動もしない。 何も起動しない — パッケージがしないこと を参照。

エンジンを起動

Section titled “エンジンを起動”

Debian/Ubuntu と RHEL/Fedora/SUSE では:

ターミナルウィンドウ
sudo systemctl enable --now olivares

OpenRC（このソースの .apk）:

ターミナルウィンドウ
sudo rc-service olivares start
# 任意。パッケージはこれをしない:
sudo rc-update add olivares default

初回起動トークンは /var/log/olivares.log にある（syslogd が動いていれば logread にも）。 OLIVARES_EXTRA_ARGS の追加フラグはグロブを無効にして空白で分割して付加される。入れ子の 引用は解釈されず、env ファイルはシェルとして評価されない。

以前に公開された Alpine には systemctl がなく、その .apk に OpenRC ユニットはない。 サービスユーザーとしてエンジンを起動する。初回起動トークンは stdout に印字される:

ターミナルウィンドウ
sudo -u olivares olivares serve --data-dir=/var/lib/olivares \
  --listen=:8443 --grpc-listen=:8444 --checkpoint-interval=1h

3. 硬化した systemd ユニット

Section titled “3. 硬化した systemd ユニット”

同梱の systemd ユニットは、空の capability bounding set を持つ非特権ユーザー olivares としてエンジンを動かす。ambient も bounding も capability を持たず、 NoNewPrivileges=true なので、起動したものが権限を得ることはない。その上に ProtectSystem=full（/usr、/boot、/efi、/etc は読み取り専用）、PrivateDevices=true、 ProtectClock=true、ProtectKernelTunables=true、ProtectKernelModules=true、 ProtectKernelLogs=true、ProtectControlGroups=true、RestrictNamespaces=user net mnt （セッションは専用のユーザー名前空間とネットワーク名前空間を持ち、フォルダーの Git フックと設定を読み取り専用に保つヘルパーは専用のマウント名前空間を持つ。その中では syscall フィルタが mount を許可する。それ以外の種類は拒否される）、 RestrictSUIDSGID=true、RestrictRealtime=true、LockPersonality=true、 SystemCallArchitectures=native、@privileged と @resources をさらに落とす @system-service syscall フィルタ、UMask=0027 を載せる。

ユニットはホームディレクトリも一時ディレクトリも隠さず、実行可能メモリを許可する。 ProtectHome=false、PrivateTmp=false、MemoryDenyWriteExecute=false を設定している。 エンジンは通常のファイル権限が olivares アカウントに許す範囲すべてに届き、/home、/tmp、 /var/tmp も含まれる。そのため、セッション用に選んだフォルダーに到達できる。閉じ込めは代わりに セッションごとに行う。各エージェントツールや stdio MCP サーバーが動く前に、エンジンは Landlock ポリシーを適用し、そのセッションフォルダー、ツールのホーム、一時ディレクトリへの書き込みを許し、 エンジンのデータディレクトリ、/etc/olivares、エンジンアカウント自身の認証情報には決して 届かせない。Node/V8 のエージェントや MCP ランタイムは実行可能な JIT メモリを必要とするため、 MemoryDenyWriteExecute=false である。Landlock のないカーネルでは、エンジンはセッションの 起動を拒否し、olivares doctor がその原因を示す。

26.10.0 はより厳しいユニットを出荷していた。データディレクトリ以外のファイルシステム全体を 読み取り専用にし、ホームを隠し、専用の /tmp を持ち、書き込み可能な実行メモリを許さなかった。 26.10.1 で上記の値に緩められた。これらの設定はドロップイン（systemctl edit olivares）で 戻せる。その場合ホームや /tmp 配下のセッションフォルダーと JIT を使うツールは動かなくなり、 ファイルシステムを読み取り専用にすると、データディレクトリ外の各セッションフォルダーに 専用の ReadWritePaths= 行が必要になる。

デフォルトの Alpine では、以前に公開された .apk にこれらの systemd 指令は適用されない。 そのペイロードの systemd ユニットが動いていないからだ。このソースから構築した .apk は代わりに OpenRC の下で動く。olivares アカウントを使い、初回起動トークンを /var/log/olivares.log に 書き、systemd のサンドボックス指令は実装しない。

リスナーはデフォルトでネットワークからの接続を受け付ける — HTTP（REST と埋め込み コンソール）は --listen=:8443、gRPC は --grpc-listen=:8444、デュアルスタックの ワイルドカードである。これはサーバーであり、守っているのは TLS 有効、デフォルト認証情報 なし、単回使用のセットアップトークンである。制限するときは /etc/olivares/olivares.env の OLIVARES_EXTRA_ARGS=--listen=127.0.0.1:8443 --grpc-listen=127.0.0.1:8444 で意図的に 行う（これらはユニット自身のフラグの後ろに追加され、後のフラグが勝つ）。手前に自分の TLS 終端を置く。IPv6 ループバックは --listen=[::1]:8443 を使う。

実行可能なスクラッチマウント

Section titled “実行可能なスクラッチマウント”

systemd ホストであらかじめ知っておくべき失敗である。症状が原因を名乗らないからだ。

プロセス外のファーストパーティコネクタは バイナリに埋め込まれて 出荷される。起動時、 エンジンは必要なものを私有スクラッチに展開し、サブプロセスとして実行する。TMPDIR が 未設定ならスクラッチは <data-dir>/tmp の下に作られる。データディレクトリが書けないときだけ システム一時ディレクトリに落ちる。明示的な TMPDIR は常に勝つ。

そのため同梱の systemd サービスはデフォルトで /tmp ではなく /var/lib/olivares/tmp を使う。実行可能なスクラッチを実際に載せるマウントを確認する:

ターミナルウィンドウ
check_scratch_mount() {
  target=${1:-/var/lib/olivares}
  opts=$(findmnt -no OPTIONS --target "$target") || {
    printf '%s\n' "cannot read mount options for $target (missing path or permission)" >&2
    return 1
  }
  [ -n "$opts" ] || {
    printf '%s\n' "mount options for $target are unknown" >&2
    return 1
  }
  case ",$opts," in
    *,noexec,*) printf '%s\n' 'noexec — set TMPDIR' ;;
    *) printf '%s\n' 'exec-capable — nothing to do' ;;
  esac
}
check_scratch_mount /var/lib/olivares

noexec と出たら、olivares ユーザーが書け、かつ 実行可能なマウント上にある ディレクトリへ TMPDIR を向ける:

ターミナルウィンドウ
sudo install -d -o olivares -g olivares -m 0750 /run/olivares-exec-tmp
sudo systemctl edit olivares      # creates a drop-in; do not edit the shipped unit
[Service]
Environment=TMPDIR=/run/olivares-exec-tmp
ReadWritePaths=/run/olivares-exec-tmp

その後再起動する。exec が EACCES または ENOEXEC で拒否された場合、エンジンのエラーは 展開マウントと 2 つの再配置制御（TMPDIR と data-dir）を名指しする。noexec マウントを 欠落コネクタとしては報告しない。

/usr/lib/systemd/system/olivares.service を直接編集せず、systemctl edit を使う。 そのファイルはパッケージのものであり、アップグレードで置き換わる。

4. 初回起動: olivares quickstart

Section titled “4. 初回起動: olivares quickstart”

quickstart は親しみやすい既定値と案内バナー付きの serve である。既定の資格情報は 決して作らない。埋め込みコンソールへ案内し、ワンタイムトークン で最初の管理者を 作らせる。

同梱の systemd ユニットですでにサーブしているなら quickstart は実行しない — 初回起動セットアップトークンはジャーナルに印字される:

ターミナルウィンドウ
journalctl -u olivares | sed -n '/FIRST-BOOT SETUP/,/========================/p'

フォアグラウンドで serve を起動した場合（デフォルトの Alpine）、同じバナーは stdout に出る。

コンソールを https://127.0.0.1:8443 で開く（初回起動時に自己署名証明書が生成される）。 そのトークンを提示して管理者を作成する。トークンは単回使用である。

ワークステーションでサービスを入れずに見るなら、olivares quickstart がフォアグラウンドで 同じことをする。既定からずらすなら --listen/--grpc-listen/--data-dir を使う。

5. 最初のソース: pgAudit

Section titled “5. 最初のソース: pgAudit”

ソースはエンジンが観測を取り込む場所である。動詞はそれぞれのコストで分かれており、その順で 使う価値がある。plan は何が変わるかを述べて何も書かない。validate は設定がそれ自体で 整合していると述べ、ネットワークには触れない。test はソースを本当に開いて応答を証明し、 set が適用する。設定は秘密の 参照（store:<name>）を運び、値は運ばない。

pgAudit は PostgreSQL の監査ログを読むので、必須フィールドは log_path だけである:

ターミナルウィンドウ
# coherent by itself? (writes nothing, opens no socket)
sudo -u olivares olivares sources validate --name pg-prod --kind pgaudit \
  --tenant <your-tenant-id> \
  --config log_path=/var/log/postgresql/postgresql.log \
  --data-dir /var/lib/olivares


# does it actually answer? (opens the source for real)
sudo -u olivares olivares sources test --name pg-prod --kind pgaudit \
  --tenant <your-tenant-id> \
  --config log_path=/var/log/postgresql/postgresql.log \
  --data-dir /var/lib/olivares


# apply it
sudo -u olivares olivares sources set --name pg-prod --kind pgaudit \
  --tenant <your-tenant-id> \
  --config log_path=/var/log/postgresql/postgresql.log \
  --actor "$(id -un)" --reason "onboard the production audit log" \
  --data-dir /var/lib/olivares

上のコマンドラインで詰め物ではない点が 3 つある。

  • --tenant は必須である。 ソースは観測が属するビジネステナントを名指ししなければならない。 なければコマンドは監査データの所有者を推測せず拒否する。
  • --actor と --reason は set だけが要求する。 特権的なオフライン操作は誰が何のために 行ったかを記録する必要がある。validate はどちらも不要である。何も書かないからだ。 この非対称こそが要点である。
  • format の既定は csvlog、follow の既定は true なので、標準的な pgAudit 配備ではどちらも不要である。

適用するとフィールドごとに何が変わったかが印字され、稼働中 のエンジンが再起動なしで 取り込む方法が示される — POST /v1/console/runtime/reload、または SIGHUP。同梱の systemd ユニットでは sudo systemctl reload olivares である。フォアグラウンドで serve を起動した場合は、そのプロセスに SIGHUP を送る。

サービスユーザーはそのログファイルへの読み取りが必要である。多くのディストリビューションでは olivares を adm または postgres グループに入れることを意味する。パッケージが代わりに 行うことではなく、あなたが意図して与える権限である。

6. アップグレード

Section titled “6. アップグレード”

更新手段はホストごとに 1 つにする。パッケージまたはリポジトリからインストールしたホストは、 そのパッケージマネージャ（apt、dnf、apk、または新しいパッケージ）で更新する。 olivares upgrade はパッケージが所有するバイナリの置き換えを拒否する。

どのパッケージインストールでも /usr/bin/olivares はパッケージマネージャが所有する （deb、rpm、apk、AUR）。そのファイルをその場で置き換えると、パッケージデータベースは もう存在しない状態のファイルを記述したままになるため、olivares upgrade は拒否する。 何かをダウンロードする前に終了コード 2 で終わり、パッケージ経由の手順を示す。更新は パッケージマネージャで行う。olivares upgrade --check は引き続き使え、計画を表示するだけで 何も変更しない。

ターミナルウィンドウ
sudo olivares upgrade --check    # what would change, without changing anything

パッケージマネージャがバイナリを所有していない場合（install.sh や手作業で置いたもの）、 olivares upgrade はそれをその場で置き換える。そこで使う理由は安全特性にある。 ダウンロードした候補の exec 探査が成功するまでバイナリを置き換えず、 タイムスタンプ付きバックアップを残し、入れ替え後の探査が失敗すればそのバックアップへ戻す。 --target <パス> は運用者による上書きで、指定したファイル（/usr/bin/olivares も含む）を 置き換える。以後、パッケージデータベースはそのファイルと一致しなくなる。

--check と --target 付きの実行で効くフラグが 3 つある。

  • --endpoint — 既定ではなく、自分が制御する GitHub リポジトリから更新を取る。 ミラーやフォークの逃げ道である。
  • --bundle — オフラインのインストールには Enterprise が必要です。Community は --bundle --check でバンドルを検証し、ライセンスの読み取りやインストールは行いません。
  • --install-timer — 予定に従って更新を確認する 任意の systemd タイマーとサービスを 出力する。何も代わりに入れてくれない。 パッケージがしないこと を参照。systemd の生成器である。 パッケージインストールでは拒否される。/usr/bin/olivares はパッケージマネージャーの管理下に あるため、--install-timer は終了コード 2 で終わり、unit を書き込まない。パッケージ マネージャーで更新する（Olivares アプライアンスでは systemctl start olivares-appliance-update.service）。

ステージングと exec 探査は インストールディレクトリ内、対象の隣 — /tmp ではない で行われるので、上で 述べた noexec マウントは アップグレードを壊さない。インストール ディレクトリ上の noexec マウントは別問題で、 インストール済みバージョンを測定不能にする。その場合、リリースチャネル、段階的ロールアウト、 ロールバックは アップグレードとロールバック にある。

7. パスを推測せずにアンインストールまたは移行する

Section titled “7. パスを推測せずにアンインストールまたは移行する”

パッケージは /var/lib/olivares/install-manifest.json を書く。アンインストーラはサービスや ファイルシステムに触れる前に、署名済み配布インデックスに対して完全なマニフェストを検証する。 想定外のパスは 2 を返す。まず検査し、保持方針を明示的に選ぶ:

ターミナルウィンドウ
sudo olivares uninstall --plan --data-dir /var/lib/olivares
sudo olivares uninstall --preserve --data-dir /var/lib/olivares
sudo olivares uninstall --purge --data-dir /var/lib/olivares --yes

Preserve はパッケージ削除の方針である。設定、データ、ログ、鍵とそのサービス識別を残す。 systemd パッケージでは削除フックが --preserve を実行する。このソースから構築した OpenRC の .apk パッケージでは、フックはサービスが稼働中なら止め、一度も有効化されていなくても失敗せずに デフォルト runlevel の項目を外し、完全なマニフェストを --plan で検証し、apk にパッケージ所有 ファイルの削除を任せる。以前に公開された Alpine パッケージは --plan での検証だけを行った。 そのペイロードには止める OpenRC ユニットがなかったからだ。消去が意図であるときだけ、パッケージを外す前に --purge を実行する。 確認が必要で、索引されたパスだけを削除する。

拠点の移動では、先に olivares dr backup を作り、先方をインストールしてそこで olivares dr restore を実行する。現行バンドルは hmac-sha256-kek-v1 でマニフェストと KEK 下の各ペイロードを認証する。より新しいエンジンからのエクスポートは書き込み前に拒否される。 別に認証された pre-v26.9 バンドルは明示的に --allow-legacy-unsigned が必要である。 バックアップと復元のガイド が KEK の保管とインポート後の 継続性証明を扱う。

8. パッケージがしないこと

Section titled “8. パッケージがしないこと”

セキュリティ製品がここで曖昧ならインストールに値しないので、はっきり書く。

  • リポジトリを追加しない。 /etc/apt/sources.list.d、/etc/yum.repos.d、 /etc/apk/repositories には何も書かない。インストールしたのは 1 ファイルであり、 入ったのもそのファイルだけである。アップグレードはあなたが起動する — 新しいパッケージで。 olivares upgrade はパッケージが所有するバイナリの置き換えを拒否する。
  • サービスを起動も有効化もしない。 systemd パッケージは systemctl があるとき systemd を 再読み込みし、systemctl enable --now を印字する。OpenRC パッケージは rc-service olivares start を印字し、rc-update add はしない。起動はあなたの判断のままで ある。稼働中の OpenRC サービスのアップグレードはそれを止め、ファイルを置き換え、再び起動する。 停止中のサービスは停止中のままである。
  • ライセンスの検証は誰にも電話しない。有料分のダウンロードはする。 オープンビルドの ライセンス検証はオフライン Ed25519 であり、遠隔キルスイッチはなく、ライセンス鍵がその ビルドを制限したり劣化させたりしない — AGPL ビルドがプラットフォーム全体である。 必須テレメトリも、デフォルトのコントロールプレーン外向き通信もない。境界を越えるのは、 越えるよう設定したものだけである — モデル API への呼び出し、配線した SIEM/webhook 出力、プロビジョニングした外部埋め込みプロバイダ、コネクタがポーリングするソース （その addr、base_url、endpoint）を、設定した間隔で。
  • しかし olivares upgrade は実行したときに意図してネットワーク呼び出しをする — それが更新確認の意味であり、--check は何か動く前に計画を見せる。約束の正直な形は: ライセンスの検証は誰にも電話しない。有料分のダウンロードはする。 更新経路も呼び出しを したくなければ --bundle を使う。
  • ネットワークへポートを開く。 ユニットは、自分で制限するまですべてのインターフェースに バインドする。

関連

Section titled “関連”