از اولین اتصال،
تا پایش روزمره سرور.

اتصال Ubuntu با Container

روش پیش‌فرض ویزارد Docker است. نیازمند Linux واقعی و Docker Engine محلی rootful است؛ Docker Desktop و Docker راه‌دور، میزبان موردنظر را تضمین نمی‌کنند. کاربر اجراکننده باید اجازه اجرای Docker داشته باشد. Agent از کانتینر اجرا می‌شود و باینری روی میزبان نصب نمی‌کند.

1. در کنسول، «افزودن زیرساخت ← سرور Linux» را انتخاب کنید و نام را برای hostname خودکار خالی بگذارید.
2. در گام اتصال، روش Docker Container را نگه دارید و توضیح دسترسی privileged را بخوانید. این سطح دسترسی برای ورود به namespaceهای میزبان است؛ محدودسازی فرمان‌های پنل جایگزین مرز امنیتی Docker نیست.
3. مجوزهای لاگ، مانیتورینگ، نصب Trivy و آپدیت بسته را انتخاب کنید. برای شل کانتینر جدید، تأیید هر نشست در Web Terminal کافی است.
4. فرمان ویزارد با یک docker run، ایمیج آماده whycloud.ir/whycloud/agent:1.10.0 را دریافت و اجرا می‌کند؛ ساخت ایمیج و نصب بسته روی سرور شما لازم نیست. این ایمیج برای Linux x86_64 است. توکن را پس از اجرا در ورودی خصوصی وارد کنید؛ برای جداشدن بدون توقف، Ctrl+P و سپس Ctrl+Q را بزنید.
5. توکن را در prompt خصوصی وارد کنید و fingerprint را در کنسول تأیید کنید. توکن داخل آرگومان docker run یا docker inspect ذخیره نمی‌شود.
6. برای جداشدن بدون توقف، Ctrl+P سپس Ctrl+Q بزنید. Docker با restart policy عامل را نگه می‌دارد؛ systemd جدا لازم نیست.

Credential و فایل‌های Stack در /var/lib/whycloud/agents/INSTANCE روی میزبان باقی می‌مانند. Container با نام whycloud-INSTANCE اجرا می‌شود. برای بررسی:

docker ps --filter name=whycloud-INSTANCE
docker logs --tail=50 whycloud-INSTANCE
docker stop whycloud-INSTANCE
docker start whycloud-INSTANCE

تغییر مجوز یا به‌روزرسانی Agent

اول Container قبلی را با docker stop متوقف و با docker rm حذف کنید؛ bind directory را نگه دارید. فرمان جدید همان زیرساخت را از ویزارد اجرا کنید. Credential حفظ می‌شود و توکن تازه لازم نیست. انتقال از Agent قدیمی به Container از مسیر credential جدا استفاده می‌کند و تأیید هویت تازه لازم است؛ Agent قدیمی را قبل از انتقال متوقف کنید.

docker stop whycloud-INSTANCE
docker rm whycloud-INSTANCE

مسیر مستقیم بومی و دستورهای systemd بخش‌های بعدی فقط برای سازگاری Agentهای قبلی هستند. داخل Container، شل پنل دسترسی root میزبان دارد؛ فقط به مدیران مورد اعتماد مجوز بدهید. مستندات: Docker run و nsenter.

آپدیت هدفمند در پنجره نگه‌داری

1. در ویزارد، مجوز آپدیت بسته را فعال کنید تا --allow-updates به Container داده شود.
2. از منو «پنجره‌های نگه‌داری»، محیط‌ها، عنوان، زمان شروع و پایان را مشخص کنید. زمان ورودی محلی مرورگر است و به UTC ذخیره می‌شود.
3. در صفحه محیط، تب Updates را باز کنید. کنار بسته، «ارتقا در پنجره نگه‌داری» را بزنید، پنجره را انتخاب و تغییر را تأیید کنید.
4. فقط نسخه Candidate همان گزارش به صف می‌رود؛ قبل از شروع پنجره اجرا نمی‌شود. صف و مراحل در نوار عملیات و اعلان‌ها دیده می‌شوند.

APT ابتدا Simulation انجام می‌دهد، سپس با only-upgrade و no-remove بسته مشخص را ارتقا می‌دهد. وابستگی‌ها ممکن است ارتقا یابند و اسکریپت‌های بسته می‌توانند سرویس را restart کنند. تنظیمات قبلی حفظ می‌شوند؛ Reboot و Rollback خودکار نداریم. پایان پنجره مانع شروع تازه است؛ عملیات شروع‌شده ممکن است بعد از پایان پنجره تکمیل شود. قطع Agent یا Timeout حین apt ممکن است بررسی dpkg --audit را لازم کند. برای زمان‌بندی آینده، ساعت میزبان باید دقیق باشد.

بازه مجاز ۱۰ دقیقه تا ۴ ساعت در ۳۰ روز آینده است. پنجره‌های هم‌پوشان برای یک محیط پذیرفته نمی‌شوند. لغو پنجره، کارهای شروع‌نشده را لغو می‌کند؛ عملیات درحال‌اجرا ناگهان قطع نمی‌شود. هر محیط فعلاً یک عملیات در صف یا اجرا دارد.

دسترسی و نویز اعلان

در «سازمان و تیم»، مالک می‌تواند نقش اعضا را تغییر دهد و مدیر می‌تواند دسترسی اعضای غیرمدیر را لغو کند. مالک و دسترسی خودتان محافظت می‌شوند. حذف عضو، شل فعال و کارهای شروع‌نشده او را می‌بندد؛ کار درحال‌اجرای سیستم‌عامل برگشت داده نمی‌شود. دعوت‌های مصرف‌نشده نیز قابل لغو هستند.

قطع‌و‌وصل هر محیط در یک خلاصه ساعتی با شمارنده تجمیع می‌شود و نشان اعلان را زیاد نمی‌کند. رویدادهای زمان Maintenance برچسب دارند. هشدارهای نیازمند اقدام روی کارت محیط و نوار جانبی دیده می‌شوند. نوار در RTL چپ و در LTR راست است؛ این جهت‌بندی به معنی ترجمه کامل انگلیسی رابط نیست.

پیش از شروع چه لازم دارید؟

یک حساب whycloud، عضویت مدیر یا مالک در سازمان، و یک میزبان Linux با معماری amd64 یا arm64. روی میزبان، Bash، curl و ابزارهای coreutils لازم‌اند. اتصال پیش‌فرض با Docker Engine محلی (rootful) انجام می‌شود؛ Container مدیریت با تأیید شما دسترسی root میزبان می‌گیرد. مسیر Agent بومی فقط برای سازگاری باقی مانده است.

همین کامپیوتر را به‌عنوان اولین سرور وصل کنید.

1. کنسول را در مرکز زیرساخت باز کنید.
2. «سرور Linux» را انتخاب کنید؛ نام را خالی بگذارید تا hostname انتخاب شود.
3. «دریافت فرمان اتصال» را بزنید؛ توکن و فرمان را در دو مرحله کپی کنید.
4. فرمان را در ترمینال همین سیستم اجرا کنید؛ Bash و Zsh هر دو قابل استفاده‌اند.
5. وقتی Enrollment token: ظاهر شد، توکن را paste و Enter بزنید.
6. ترمینال را باز نگه دارید. اثر انگشت نمایش‌داده‌شده در ترمینال را با کارت «تأیید هویت» در ویزارد تطبیق دهید؛ سپس گزینه تطبیق و دکمه تأیید را بزنید. اتصال ناشناس را رد کنید.

خروجی موفق چه شکلی است؟

Connected to whyconnect
Server snapshot accepted

گزارش‌ها تقریباً هر ۱۰ ثانیه ارسال می‌شوند. اولین بررسی IP ممکن است تا گزارش بعدی طول بکشد. Ctrl+C اتصال را متوقف می‌کند؛ برای اتصال دوباره همان فرمان ویزارد را اجرا کنید. اگر هویت ذخیره شده باشد، توکن دوباره درخواست نمی‌شود.

اگر curl نصب نیست

روی Debian/Ubuntu:

sudo apt update
sudo apt install curl ca-certificates

روی Fedora/RHEL:

sudo dnf install curl ca-certificates

برای دیدن اطلاعات میزبان، از Container رسمی ویزارد با مجوز namespace استفاده کنید؛ اجرای یک کانتینر معمولی بدون این تنظیمات، اطلاعات همان کانتینر را نشان می‌دهد.

نام خودکار؛ با اختیار تغییر.

در حالت پیش‌فرض hostname سیستم نام نمایشی سرور می‌شود و با گزارش‌های بعدی به‌روز می‌ماند. در شروع می‌توانید بخش «می‌خواهم نام دلخواه انتخاب کنم» را باز کنید. بعداً هم دکمه «ویرایش نام» در صفحه سرور در دسترس است. خالی‌کردن نام، حالت خودکار را برمی‌گرداند. hostname واقعی سیستم هیچ‌گاه از کنسول تغییر داده نمی‌شود.

اتصال جدید نیازمند تأیید شماست

هر عامل تازه، چه سرور و چه Kubernetes، ابتدا «در انتظار تأیید» است. مدیر یا مالک سازمان باید اثر انگشت هویت نمایش‌داده‌شده در ترمینال عامل را با کارت کنسول مقایسه کند. نام میزبان و IP به‌تنهایی اثبات هویت نیستند. پیش از تأیید، فقط مشخصات اولیه میزبان نمایش داده می‌شود؛ کاربران، لاگ SSH و گزارش اسکن سرور ذخیره یا نمایش داده نمی‌شوند. عامل Linux نسخه 1.2 نیز جمع‌آوری این گزارش‌ها و اسکن را تا تأیید متوقف می‌کند.

این درخواست در ویزارد، صفحه زیرساخت و «اعلان‌ها و اقدامات» قابل مشاهده است. رد درخواست، اعتبار آن هویت را لغو می‌کند. تاریخچه صدور توکن، اتصال، تأیید یا رد، دریافت اولین گزارش و قطع ارتباط در صفحه زیرساخت دیده می‌شود. اتصال‌های قدیمی هنگام ارتقا نیز یک بار نیازمند تأیید می‌شوند.

توکن اولیه ۱۵ دقیقه اعتبار دارد و یک‌بارمصرف است. پس از ثبت، یک هویت جداگانه با مجوز فایل 0600 روی میزبان ذخیره می‌شود. برای هر سرور یک فایل جدا وجود دارد:

${XDG_CONFIG_HOME:-$HOME/.config}/whycloud/servers/INSTANCE.json

در این مسیر INSTANCE همان شناسه سرور در فرمان ویزارد است. از بخش راهنمای همان سرور وارد شوید تا مسیر دقیق نمایش داده شود.

توکن و فایل هویت را در Git یا کانال‌های عمومی قرار ندهید. هر هویت فقط به یک زیرساخت در یک سازمان تعلق دارد. با «لغو دسترسی عامل»، ارسال گزارش با آن هویت متوقف می‌شود.

IP خروجی چطور شناسایی می‌شود؟

عامل با یک درخواست HTTPS به ip.mci.dev و ipify آدرس عمومی مسیر خروج خود را می‌خواند. توکن، hostname و اطلاعات کاربران به این سرویس ارسال نمی‌شوند. بررسی هنگام شروع و سپس هر ۱۰ دقیقه تکرار می‌شود؛ نتیجه با گزارش بعدی به کنسول می‌رسد.

اگر سرویس تشخیص IP در دسترس نباشد، اتصال سرور ادامه دارد و وضعیت «IP خروجی در دسترس نیست» همراه زمان بررسی نمایش داده می‌شود؛ IP قدیمی به‌جای نتیجه تازه نشان داده نمی‌شود. برای آزمایش دستی:

curl --max-time 10 'https://api64.ip.mci.dev و ipify.org?format=json'

عامل متغیرهای استاندارد HTTPS_PROXY، HTTP_PROXY و NO_PROXY را رعایت می‌کند. برای اجرای systemd، تنظیمات پراکسی نشست ترمینال خودکار منتقل نمی‌شوند؛ در صورت نیاز آن‌ها را در تنظیمات سرویس خود تعریف کنید.

لاگ SSH را به داشبورد بیاورید.

عامل حداکثر ۱۰۰ رویداد sshd و sshd-session از ۲۴ ساعت اخیر journal را می‌خواند. اگر journal قابل خواندن نباشد، انتهای فایل /var/log/auth.log یا /var/log/secure بررسی می‌شود. در حالت فایل، بازه مربوط به فایل فعلی است و چرخش لاگ ممکن است رویدادهای قبلی را حذف کرده باشد.

id
journalctl -t sshd -t sshd-session --since '24 hours ago' -n 10

اگر کاربر عامل مجوز ندارد، مدیر سیستم می‌تواند دسترسی خواندن journal را اضافه کند. این گروه امکان خواندن سایر لاگ‌های سیستم را هم می‌دهد:

sudo usermod -aG systemd-journal "$USER"

از نشست خارج و دوباره وارد شوید و عامل را مجدداً اجرا کنید؛ پردازش قبلی گروه جدید را دریافت نمی‌کند. روی برخی توزیع‌ها عضویت در adm برای خواندن فایل‌های احراز هویت کافی است.

یک رویداد آزمایشی بسازید

اگر OpenSSH Server از قبل نصب و فعال است:

ssh "$USER"@localhost
# After login:
exit

اگر Connection refused دریافت کردید، SSH Server احتمالاً فعال نیست. برای اتصال عامل نیازی به فعال‌کردن SSH یا بازکردن پورت ورودی ندارید. «منبع قابل خواندن ولی بدون رویداد» و «نبود مجوز خواندن» جداگانه نمایش داده می‌شوند.

نصب Trivy با اجازه شما

در مجوزهای اختیاری ویزارد، نصب ابزار را فعال کنید (--allow-install). سپس کارت Trivy، دکمه نصب و تأیید جداگانه دارد. ایمیج aquasec/trivy:0.75.0 دریافت و اجرای آن بررسی می‌شود. اسکن در کانتینر موقت با فایل‌سیستم میزبان فقط‌خواندنی انجام می‌شود؛ Docker socket در اختیار اسکنر نیست و کش CVE در Volume محلی باقی می‌ماند. پیشرفت در پنل سمت چپ و اعلان‌ها نمایش داده می‌شود. برای اسکن، گزینه --scan هم باید فعال باشد. بدون این گزینه نصب به‌تنهایی اسکن را شروع نمی‌کند.

اسکن آسیب‌پذیری بسته‌ها با Trivy.

گزینه اسکن در ویزارد، عامل را با --scan اجرا می‌کند. در کارت Trivy نصب کانتینری را تأیید کنید. Docker Engine محلی و امکان دریافت ایمیج و پایگاه CVE لازم است. نصب باینری دستی روی میزبان لازم نیست.

اسکن اولیه پس از تأیید هویت در پس‌زمینه انجام می‌شود و هر ۶ ساعت تکرار می‌شود. دریافت دیتابیس نیازمند اینترنت است. برای شروع اسکن تازه، عامل را با گزینه اسکن مجدداً اجرا کنید. شدت CVE، بسته، نسخه نصب‌شده و نسخه اصلاح‌شده در داشبورد نمایش داده می‌شود.

Prometheus و Thanos روی میزبان خودتان.

پس از اتصال و تأیید VM، کارت «مانیتورینگ روی زیرساخت شما» در داشبورد نمایش داده می‌شود. عامل باید نسخه 1.5 باشد. در «اتصال و راهنما»، گزینه «مجوز مدیریت Monitoring Stack» را فعال و فرمان را روی میزبان اجرا کنید. این گزینه فقط عملیات ثابت نصب/راه‌اندازی و توقف را مجاز می‌کند؛ مجوز Shell جداگانه فعال می‌شود.

تشخیص Docker و پیشنهاد نصب

Agent نسخه و دسترسی Docker، Compose، Containerهای فعال و وجود Trivy را تشخیص می‌دهد. اگر Docker محلی آماده باشد، پنل نصب Stack میزبان و Container را پیشنهاد می‌دهد. Docker context راه‌دور پذیرفته نمی‌شود. Exporter برنامه‌هایی مثل PostgreSQL به credential اختصاصی نیاز دارد و در این نسخه خودکار نصب نمی‌شود.

پیش‌نیازها

• Linux و Docker Engine محلی با Compose v2؛ نصب Docker طبق راهنمای رسمی Ubuntu انجام شود. عامل خودش Docker نصب نمی‌کند.
• فرمان‌های docker info و docker compose version باید برای همان کاربر عامل موفق باشند. دسترسی به Docker معادل دسترسی سطح بالای میزبان است.
• دسترسی خروجی به Docker Hub، quay.io و ghcr.io برای دریافت Imageها؛ Docker daemon پراکسی مستقل از عامل دارد.
• حدود ۲ GiB حافظه آزاد و فضای کافی برای TSDB. Retention پیش‌فرض ۱۵ روز یا ۵ GB است؛ WAL و Imageها فضای اضافه نیاز دارند.
• پورت‌های loopback با شماره‌های 18080، 19090، 19100 و 19190 تا 19193 باید آزاد باشند. تنها یک Stack مدیریت‌شده روی هر میزبان پشتیبانی می‌شود.

اجزای نصب‌شده

Prometheus برای ذخیره محلی؛ Thanos Sidecar و Query برای خواندن متریک‌ها؛ Node Exporter برای میزبان؛ cAdvisor برای Containerها. cAdvisor به‌صورت privileged و با mountهای میزبان اجرا می‌شود؛ تأیید نصب در پنل این دسترسی را توضیح می‌دهد. همه Endpointها فقط روی loopback قرار دارند.

مسیر ارتباط و مالکیت داده

Ubuntu Agent ── outbound HTTPS/WSS ──> whycloud
  ├─ polls approved operations
  ├─ reports progress and telemetry
  └─ reads local Thanos Query
       └─ Sidecar → Prometheus → Node Exporter / cAdvisor

whycloud هیچ اتصال SSH یا ورودی به میزبان باز نمی‌کند. درخواست پنل در PostgreSQL ثبت می‌شود؛ خود عامل آن را دریافت می‌کند. وضعیت queued، preflight، download، start، verify و نتیجه در صفحه VM و اعلان‌ها دیده می‌شود. متریک‌های خام و TSDB روی میزبان باقی می‌مانند؛ آخرین خلاصه و نمودار یک ساعت اخیر در whycloud ذخیره می‌شود. این نسخه Object Storage، HA یا ذخیره بلندمدت خارج از میزبان را پیکربندی نمی‌کند.

راه‌اندازی و توقف

1. در کارت مانیتورینگ، «راه‌اندازی مانیتورینگ» را بزنید و فهرست اجزا و دسترسی‌ها را تأیید کنید.
2. عامل هر پنج ثانیه صف خود را بررسی می‌کند. دریافت Imageها ممکن است چند دقیقه طول بکشد.
3. پس از Health check، وضعیت Healthy و targetهای UP را می‌بینید. برای نمودار CPU چند دقیقه نمونه‌برداری لازم است.
4. «توقف Stack» فقط Containerهای مدیریت‌شده را متوقف و Volume متریک‌ها را حفظ می‌کند.

فایل‌های Compose در پوشه monitoring-* کنار credential همان عامل ذخیره می‌شوند. برای بررسی محلی از نام project در docker compose ls استفاده کنید؛ سپس با همان project و مسیر فایل Compose، ps و logs --tail=100 را اجرا کنید. Volume فقط با اقدام صریح شما روی میزبان پاک می‌شود.

خطاها و بازیابی

نبود Docker یا مجوز، اشغال پورت، مشکل دریافت Image و شکست Health check جداگانه گزارش می‌شوند. عملیات ناموفق خودکار تکرار نمی‌شود. اگر عامل حین عملیات قطع شود، پس از پایان مهلت نتیجه نامشخص/ناموفق اعلام می‌شود؛ ابتدا وضعیت میزبان را بررسی و سپس درخواست تازه بدهید. برای Stack نیمه‌نصب‌شده، Containerها جهت عیب‌یابی حفظ می‌شوند.

داشبورد Ubuntu

Overview شامل CPU، Memory، Network I/O، دیسک‌های قابل استفاده، Processهای پرمصرف از نظر RSS و هشدارهای ظرفیت است. Services & Ports وضعیت systemd و Listenerها را نشان می‌دهد. Updates از Cache محلی apt می‌خواند و هیچ بسته‌ای نصب نمی‌کند. وضعیت reboot-required نیز نمایش داده می‌شود. مجوز یا ابزار ناموجود با وضعیت unavailable گزارش می‌شود.

شل واقعی، با اتصال خروجی از میزبان.

1. عامل قبلی را متوقف کنید. در «اتصال و راهنما»، بخش مجوزهای اختیاری را باز و «شل تعاملی» را فعال کنید. فرمان جدید شامل --allow-shell می‌شود.
2. فرمان جدید را روی همان میزبان اجرا کنید. هویت قبلی حفظ می‌شود؛ توکن تازه لازم نیست.
3. پس از دریافت گزارش تازه، در تب Terminal دسترسی شل را تأیید و ترمینال را باز کنید.
4. برای تست، whoami، hostname و uptime را اجرا کنید. Bash تعاملی، تغییر اندازه و Ctrl+C پشتیبانی می‌شود.
5. «قطع نشست» یا خروج از تب، نشست را می‌بندد. حداکثر اعتبار ۱۵ دقیقه است؛ نبود ارتباط مرورگر برای ۶۰ ثانیه نیز آن را منقضی می‌کند.

فقط Owner و Admin می‌توانند شل باز کنند. دستورات با کاربر سیستم‌عامل Agent اجرا می‌شوند و ممکن است میزبان را تغییر دهند؛ sudo به‌صورت خودکار اجرا نمی‌شود. هر Agent یک نشست فعال دارد و نشست فقط برای سازنده آن قابل دسترس است. آغاز و پایان در Audit ثبت می‌شود؛ ورودی و خروجی شل فقط در حافظه محدود نگه‌داری می‌شوند. پردازش‌هایی که خودتان عمداً daemonize می‌کنید ممکن است پس از پایان نشست باقی بمانند.

شناسه اختصاصی سازمان

هر سازمان یک Connect ID پایدار دارد. ثبت عامل جدید، مسیر /connect/org/CONNECT_ID/ws را برمی‌گرداند و whyconnect تطابق سازمانِ credential با مسیر را بررسی می‌کند. credential همچنان مخصوص همان زیرساخت و عامل است؛ دانستن مسیر مجوز اتصال نیست. مسیر قدیمی فقط برای سازگاری عامل‌های قبلی باقی مانده است. Telemetry با WSS و درخواست شل، لاگ و عملیات با HTTPS خروجی خود Agent تبادل می‌شوند؛ هیچ پورت ورودی روی میزبان لازم نیست.

لاگ‌های مهم، زنده و قابل جست‌وجو.

در مجوزهای اختیاری، ارسال لاگ را فعال کنید تا --allow-logs به فرمان اضافه شود. تب Logs شامل SSH، Docker daemon و رویدادهای Warning تا Emergency در journal است. Agent هر سه ثانیه رویدادهای تازه را ارسال می‌کند؛ در شروع، حداکثر ۲۰۰ رویداد از ده دقیقه اخیر خوانده می‌شود. این سرویس آرشیو کامل لاگ نیست.

بازه ۱۵ دقیقه، یک ساعت یا شش ساعت را انتخاب کنید؛ متن پیام و Source مانند sshd قابل فیلتر است. گزینه Live استریم را کنترل می‌کند و «خروجی JSONL» همه رویدادهای باقی‌مانده مطابق فیلتر را دانلود می‌کند. در پنل حداکثر ۵۰۰ رویداد نمایش داده می‌شود؛ نگه‌داری در PostgreSQL حداکثر ۶ ساعت یا ۳۰۰۰ رویداد به‌ازای زیرساخت است. اعضای همان سازمان به این لاگ‌ها دسترسی دارند.

دسترسی journal به کاربر Agent بستگی دارد. وضعیت limited یعنی فقط رویدادهای قابل خواندن ارسال می‌شوند؛ دسترسی به گروه systemd-journal را مدیر میزبان تعیین می‌کند. داده حساس داخل متن لاگ به پنل منتقل می‌شود؛ پیش از فعال‌سازی، محتوای لاگ برنامه‌های خود را بررسی کنید.

عامل را پس از بستن ترمینال هم اجرا کنید.

روش ساده: در ویزارد گزینه «اجرای دائمی Agent با systemd user» را فعال کنید. فرمان با --service سرویس کاربری مخصوص همین شناسه را نصب و اجرا می‌کند. ابتدا نمونه ترمینالی قبلی را متوقف کنید. برای کارکرد پس از logout، lingering لازم است. روش دستی زیر نیز قابل استفاده است.

اول اتصال آزمایشی را انجام دهید و عامل ترمینال را با Ctrl+C متوقف کنید. سپس سرویس کاربری زیر را بسازید. اگر این صفحه را از راهنمای سرور باز کرده باشید، شناسه سرور در فرمان جای‌گذاری شده است؛ در غیر این صورت INSTANCE را با شناسه موجود در فرمان اتصال عوض کنید.

mkdir -p "$HOME/.config/systemd/user"
cat > "$HOME/.config/systemd/user/whycloud-INSTANCE.service" <<'UNIT'
[Unit]
Description=whycloud server monitoring
After=network-online.target

[Service]
ExecStart=%h/.local/bin/whycloud-agent run --config %h/.config/whycloud/servers/INSTANCE.json --scan
Environment=PATH=/usr/local/bin:/usr/bin:/bin
Restart=on-failure
RestartSec=10
NoNewPrivileges=true
UMask=0077

[Install]
WantedBy=default.target
UNIT
systemctl --user daemon-reload
systemctl --user enable --now whycloud-INSTANCE
journalctl --user -u whycloud-INSTANCE -f

این فرمان مسیر پیش‌فرض نصب را فرض می‌کند. اگر XDG_CONFIG_HOME یا WHYCLOUD_BIN_DIR را تغییر داده‌اید، مسیرهای ExecStart را مطابق خروجی نصب‌کننده اصلاح کنید. اگر اسکن نمی‌خواهید، --scan را حذف کنید. برای باقی‌ماندن سرویس پس از خروج کاربر، مدیر سیستم می‌تواند این فرمان را اجرا کند:

sudo loginctl enable-linger "$USER"

برای اجازه مدیریت Stack در سرویس، --allow-monitoring را به ExecStart اضافه و سرویس را restart کنید. این مجوز به‌صورت پیش‌فرض فعال نیست. یک هویت را هم‌زمان در ترمینال و سرویس اجرا نکنید؛ اتصال جدید جایگزین اتصال قبلی همان عامل می‌شود.

یک میزبان دیگر را متصل کنید.

localhost همیشه به خود همان دستگاه اشاره دارد. برای سرور دور، کنسول باید آدرس HTTPS قابل دسترس داشته باشد. مقدار PUBLIC_ORIGIN باید با آن آدرس یکسان و COOKIE_SECURE=true باشد. reverse proxy باید WebSocket مسیر /connect/org/CONNECT_ID/ws را عبور دهد.

1. کنسول را از آدرس HTTPS نهایی باز کنید.
2. یک زیرساخت جدید بسازید؛ فرمان ویزارد همان آدرس را استفاده می‌کند.
3. با SSH به سرور مقصد وارد شوید و فرمان را آنجا اجرا کنید.
4. توکن مخصوص همان زیرساخت را وارد کنید و نتیجه را در کنسول ببینید.

عامل ارتباط ورودی ندارد. دسترسی خروجی به کنسول، و برای تشخیص IP به ip.mci.dev و ipify لازم است. برای اسکن هم دسترسی دیتابیس Trivy لازم خواهد بود. HTTP فقط روی آدرس‌های loopback برای تست محلی پذیرفته می‌شود.

راه‌اندازی DNS محلی

Agent 1.6، Linux با Docker محلی و مجوز نصب کامپوننت لازم است. در ویزارد اتصال، گزینه نصب کامپوننت را فعال کنید. سپس در «مدیریت DNS»، دامنه، سرور و IP موجود روی اینترفیس را انتخاب کنید. پورت ۵۳ TCP و UDP باید آزاد باشد. Agent سرویس‌های DNS موجود را متوقف نمی‌کند.

پس از تأیید، کانتینر Authoritative و Volume اختصاصی ساخته می‌شود. رکوردهای SOA و NS اصلی و ns1 خودکار هستند. رکوردهای A، AAAA، CNAME، MX، TXT و NS از کنسول قابل مدیریت‌اند. Apply باعث Restart کوتاه می‌شود؛ برای دامنه عملیاتی پنجره تغییر مناسب انتخاب کنید. توقف، Volume را حذف نمی‌کند.

برای تست روی خود سیستم، یک IP واقعاً موجود از فهرست انتخاب کنید و پس از Healthy شدن با dig @IP example.com SOA و dig @IP www.example.com A بررسی کنید. انتخاب IP لوپ‌بک فقط برای دسترسی محلی است. برای دسترسی از شبکه، Firewall پورت ۵۳ هر دو پروتکل را بررسی کنید. برای دامنه عمومی، NS و Glue باید در Registrar تنظیم شوند؛ صرف ساخت سرویس این تنظیم را انجام نمی‌دهد.

این نسخه Resolver باز یا کش Recursive ارائه نمی‌دهد. GeoDNS، DNSSEC، سرویس Public و افزودن خودکار IP جدید هنوز فعال نیستند. IP جدید را ابتدا با روش مدیریت شبکه میزبان اضافه کنید؛ سپس ویزارد را دوباره باز کنید. متریک Probe مدت پاسخ SOA است و نرخ درخواست‌های کاربران نیست. متریک‌ها از مسیر Node Exporter → Prometheus → Thanos روی میزبان جمع می‌شوند؛ نمودار یک ساعت اخیر در کنسول دیده می‌شود. اگر Stack مانیتورینگ قدیمی دارید، با Agent جدید گزینه راه‌اندازی مجدد Stack را تأیید کنید تا Textfile Collector فعال شود.

لاگ کانتینر Agent

با docker logs --tail 100 --follow whycloud-INSTANCE لاگ را ببینید. خروجی JSON شامل زمان، سطح و event است. اتصال، انتظار تأیید، پیشرفت عملیات و باز و بسته‌شدن شل ثبت می‌شوند؛ متن شل و توکن ثبت نمی‌شوند. telemetry.healthy حداکثر هر پنج دقیقه ثبت می‌شود. برای جزئیات موقت WHYCLOUD_LOG_LEVEL=debug و برای قالب متنی WHYCLOUD_LOG_FORMAT=text را پیش از فرمان اتصال export کنید. نصب‌کننده چرخش لاگ ۳ فایل ۱۰ مگابایتی را تنظیم می‌کند.

فرمان کوتاه ویزارد اسکریپت container-connect.sh را از همین کنسول دریافت می‌کند؛ اسکریپت، docker build و docker run را با تنظیمات ثابت اجرا می‌کند. برای به‌روزرسانی، کانتینر قبلی همین شناسه را متوقف و حذف کنید، Volume هویت را نگه دارید و فرمان جدید را اجرا کنید. restart ایمیج را به‌روزرسانی نمی‌کند.

اگر اتصال کامل نشد.

docker compose ps
docker compose logs --tail=80 connect account

این فرمان‌ها را در پوشه real-console روی میزبان کنسول اجرا کنید. هنگام ارسال لاگ برای پشتیبانی، توکن‌ها و اطلاعات حساس را حذف کنید.

توقف، لغو دسترسی و حذف.

اجرای ترمینالی با Ctrl+C متوقف می‌شود. برای سرویس کاربری:

systemctl --user disable --now whycloud-INSTANCE
rm "$HOME/.config/systemd/user/whycloud-INSTANCE.service"
systemctl --user daemon-reload

در صفحه سرور «Revoke دسترسی عامل» را بزنید. برای حذف رکورد از کنسول، «حذف زیرساخت» را انتخاب و نام آن را وارد کنید. این کار credentialها را لغو و گزارش ذخیره‌شده را حذف می‌کند، اما VM یا Stack محلی را پاک نمی‌کند. پیش از حذف، اگر نیاز دارید Stack را متوقف کنید. گزارش قبلی با وضعیت قدیمی باقی می‌ماند. برای حذف هویت همان سرور، فایل whycloud/servers/INSTANCE.json را از پوشه تنظیمات خود حذف کنید. باینری ~/.local/bin/whycloud-agent مشترک همه هویت‌هاست؛ فقط وقتی هیچ نمونه‌ای نیازش ندارد آن را حذف کنید.