- استفاده از Hermes
- دامنه مدیریتشده
دامنه مدیریتشده
دامنه مدیریتشده به یک مدیر اجازه میدهد تا پیکربندی پایه و رمزهای عبور را به کاربران استاندارد (غیر root) تحمیل کند و آنها نتوانند آنها را تغییر دهند. این قابلیت برای استقرارهای ناوگان/سازمانی در نظر گرفته شده است، جایی که بخش IT نیاز دارد مثلاً ارائهدهنده مدل، آدرس base URL مشترک API، یا security.redact_secrets: true را برای هر کاربر روی یک ماشین ثابت نگه دارد.
security.redact_secrets: true
وقتی یک دامنه مدیریتشده وجود دارد، مقادیری که مشخص میکند بر مقادیر ~/.hermes/config.yaml، ~/.hermes/.env و حتی محیط shell کاربر اولویت دارد — دقیقاً برای کلیدهایی که ثابت میکند. بقیه تنظیمات کاملاً تحت کنترل کاربر باقی میمانند.
~/.hermes/config.yaml
~/.hermes/.env
نصب توسط مدیر بسته (distro بیانی / formula) تمام تغییرات پیکربندی را مسدود میکند و به شما میگوید از مدیر بسته خود استفاده کنید. دامنه مدیریتشده مکانیزم جداگانهای است: مقادیر غیرقابل تغییر مشخصی را به صورت کلید-به-کلید تزریق میکند، نه اینکه کل پیکربندی را قفل کند. این دو مکانیزم مستقل هستند و میتوانند همزمان وجود داشته باشند.
محل قرارگیری
دامنه مدیریتشده از یک فهرست سطح سیستم خوانده میشود، که به صورت پیشفرض /etc/hermes است:
/etc/hermes
/etc/hermes/
├── config.yaml # managed config layer (wins over ~/.hermes/config.yaml)
└── .env # managed env layer (wins over ~/.hermes/.env + shell)
فهرست و فایلها متعلق به root هستند (حالت فهرست 0755، فایلها 0644): برای همه قابل خواندن، فقط توسط مدیر قابل نوشتن است. مجوز فایلسیستم مکانیزم اجرایی است — یک کاربر استاندارد میتواند فایلهای مدیریتشده را بخواند اما نمیتواند آنها را ویرایش کند.
root
0755
0644
هر کدام از فایلها اختیاری هستند. نبود فهرست مدیریتشده یا فایل به سادگی به معنای «بدون دامنه مدیریتشده» است و پیکربندی دقیقاً مانند زمانی که این قابلیت وجود ندارد حل میشود.
جابهجایی فهرست
مکان را میتوان با متغیر محیطی HERMES_MANAGED_DIR (برای کانتینرها یا استقرارهای غیر /etc) تغییر داد. این یک تنظیم مسیر استقرار/راهاندازی اولیه است — مانند HERMES_HOME — که توسط همان مدیری که فایلهای مدیریتشده را مالکیت میکند تنظیم میشود. هرگز توسط Hermes در هیچ .env ذخیره نمیشود.
HERMES_MANAGED_DIR
/etc
HERMES_HOME
.env
# Point managed scope at a custom directory (set by IT / the deployment, not the user)
export HERMES_MANAGED_DIR=/opt/org/hermes-policy
کاربری که بتواند HERMES_MANAGED_DIR را تنظیم کند میتواند دامنه مدیریتشده را به فهرستی که خودش کنترل میکند منتقل کند و آن را بیاثر کند. در یک استقرار واقعی، این متغیر باید توسط مدیر ثابت شود (مثلاً در واحد سرویس / تصویر کانتینر قرار گیرد)، نه اینکه قابل تنظیم توسط کاربر باشد. hermes doctor فهرست مدیریتشده حلشده را گزارش میدهد تا هرگونه تغییر مسیر قابل مشاهده باشد.
HERMES_MANAGED_DIR
hermes doctor
اولویتبندی
برای کلیدهایی که لایه مدیریتشده مشخص میکند، ترتیب اولویت (بالاترین اولویت دارد):
| لایه | config.yaml | .env |
|---|---|---|
| 1 | /etc/hermes/config.yaml (مدیریتشده) |
/etc/hermes/.env (مدیریتشده) |
| 2 | ~/.hermes/config.yaml (کاربر) |
~/.hermes/.env (کاربر) |
| 3 | مقادیر پیشفرض داخلی | محیط shell موجود |
/etc/hermes/config.yaml
/etc/hermes/.env
~/.hermes/config.yaml
~/.hermes/.env
ادغام در سطح برگ انجام میشود: ثابت کردن model.default بقیه model.* را فریز نمیکند. یک config.yaml مدیریتشده مانند زیر:
model.default
model.*
config.yaml
model:
default: org/standard-model
model.default را برای هر کاربر اجباری میکند در حالی که model.fallback (و هر کلید دیگر) تحت کنترل کاربر باقی میماند.
model.default
model.fallback
برای کلیدهایی که ثابت میکند، دامنه مدیریتشده عمداً بر محیط shell هم اولویت دارد — در غیر این صورت «مدیریتشده» نبود. این تنها جایی است که قاعده معمول «متغیر محیطی بر config.yaml اولویت دارد» را معکوس میکند و فقط برای کلیدهای مشخصی که لایه مدیریتشده تعیین میکند اعمال میشود.
مشاهده آنچه مدیریت میشود
hermes config # shows a header naming the managed source + the pinned keys
hermes doctor # reports the resolved managed dir + pinned key counts
اگر سعی کنید مقدار مدیریتشدهای را تغییر دهید، Hermes رد میکند و منبع را نام میبرد:
$ hermes config set model.default my/model
Cannot set 'model.default': it is managed by your administrator
(/etc/hermes/config.yaml) and cannot be changed.
همین موضوع در مورد رمزهای عبور مدیریتشده هم صادق است — hermes config set مقدار کاربر را برای کلید env که توسط .env مدیریتشده ثابت شده نمینویسد.
hermes config set
.env
راهاندازی دامنه مدیریتشده (مدیران)
sudo mkdir -p /etc/hermes
# Pin some config values for every user on this machine
sudo tee /etc/hermes/config.yaml >/dev/null <<'YAML'
model:
provider: nous
security:
redact_secrets: true
YAML
# Optionally pin a shared, non-sensitive env value
sudo tee /etc/hermes/.env >/dev/null <<'ENV'
OPENAI_API_BASE=https://inference.example.com/v1
ENV
sudo chmod 0755 /etc/hermes
sudo chmod 0644 /etc/hermes/config.yaml /etc/hermes/.env
تغییرات در شروع بعدی Hermes اعمال میشوند (یک فایل مدیریتشده نادرست با شدت بالا لاگ میشود و نادیده گرفته میشود — هرگز شروع را مسدود نمیکند، اما مدیر باید hermes doctor را بررسی کند تا مطمئن شود سیاست اعمال میشود).
hermes doctor
مدل امنیتی و محدودیتها (v1)
- اجرا فقط از طریق مجوزهای فایلسیستم انجام میشود. اگر کاربر به فهرست مدیریتشده دسترسی نوشتن داشته باشد (یا Hermes را به عنوان root اجرا کند)، دامنه مدیریتشده فقط توصیهای است.
.envمدیریتشده برای همه قابل خواندن (0644) است، بنابراین هر کاربر محلی میتواند رمزهای عبوری که از طریق آن ارسال میشوند را بخواند. از آن برای مقادیر مشترک غیرحساس (آدرس base URL سازمانی، مقادیر پیشفرض ویژگیها) به جای رمزهای عبور با حساسیت بالا استفاده کنید.- ابزارهای خود عامل از مقدار
.envمدیریتشده به صورت سخت مسدود نیستند. متغیر محیطی مدیریتشده در شروع اعمال میشود، اما هیچ چیز مانع از تنظیم مقدار متفاوتی توسط عامل در shell فرعی خودش نمیشود. v1 یک مرز راحتی مدیریتی در برابر کاربر عادی است، نه یک sandbox غیرقابل فرار.
root
.env
0644
موارد زیر عمداً خارج از م scope v1 هستند و ممکن است بعداً اضافه شوند:
- مرز سختی که خود عامل نتواند از آن فرار کند.
- مکانهای مدیریتشده بومی در macOS و Windows (v1 اولویت با Linux/POSIX است).
- فهرستهای قطعهای (managed.d/) برای سیاست لایهای.
- فایلهای مدیریتشده امضاشده / بررسیشده از نظر یکپارچگی.
- تحویل راه دور / مدیریت دستگاه (MDM).
- مجوزهای دقیقتر (با دامنه گروهی) برای رمزهای عبور مدیریتشده.
managed.d/
ویرایش این صفحه