تشغيل عقدة AeroNyx وفحصها: الصحة والترقية والتراجع

Q: ما الأمر الذي يجب أن أشغّله أولًا عندما يبدو أن هناك خطأ ما؟

شغّل ./deploy/node/aeronyx-node.sh status --repo-dir "$PWD" بصلاحيات root. يعرض حالة الخدمة والصحة المحلية والاكتشاف والخطوة التالية الموصى بها، ولا يغيّر المضيف.

Q: ما الفرق بين relay-probe وrelay-smoke؟

يرسل relay-probe مغلّفًا معتمًا اصطناعيًا واحدًا، ولا يُظهر إلا أن مسار المُرحِّل يقبل حركة المرور. أما relay-smoke فيعمل بوصفه عميلًا حقيقيًا: يتحقق من إيصال نهائي موقّع ومن سحب كامل من صندوق البريد والإقرار باستلام رسالة اختبار مشفّرة واحدة.

Q: هل يمكنني الترقية دون قطع اتصال المستخدمين؟

يمكنك بناء ترقية وتجهيزها باستخدام --no-restart أثناء اتصال المستخدمين. أما الانتقال إلى الإصدار الجديد فيحتاج إلى إعادة تشغيل، لذا فرّغ العقدة باستخدام وضع الصيانة ثم شغّل upgrade --skip-pull.

Q: كيف أعود إلى الإصدار السابق؟

تتراجع الترقية الفاشلة تلقائيًا. للتراجع لاحقًا، استخدم promote-binary مع إحدى النسخ الاحتياطية في /var/lib/aeronyx/releases/؛ ويتطلب ذلك صفر جلسات نشطة، ويستعيد الملف التنفيذي السابق إذا لم يكن الملف المُرقّى سليمًا.

يغطي دليل التشغيل هذا الأوامر اليومية لعقدة AeroNyx مسجّلة: الحالة، والصحة، والسجلات، وإثباتات المُرحِّل وصندوق البريد، والترقيات الآمنة، والتراجع، وما يجب فحصه بعد إعادة التشغيل. جميع الأوامر موجودة في مستودع العقدة (deploy/node/aeronyx-node.sh والملف التنفيذي aeronyx-server)، وهي معروضة بالخيارات التي تقبلها الشيفرة.

إذا لم تكن قد ثبّتّ عقدة بعد، فابدأ بـ تثبيت عقدة AeroNyx وتسجيلها.

قبل أن تبدأ

شغّل كل شيء من صدفة بصلاحيات root (sudo -i). مجلد الإعداد /etc/aeronyx ومجلد الحالة /var/lib/aeronyx بالوضع 700، لذا لا تستطيع أوامر الحالة والصحة والتحقق من الصحة والمُرحِّل قراءتهما عند تشغيلها بمستخدم آخر.

انتقل إلى المستودع الذي تعمل منه الخدمة فعليًا، ومرّره باستخدام --repo-dir في كل أمر من أوامر السكربت. فبدون --repo-dir يفترض السكربت المسار /opt/aeronyx/AeroNyx.

bash

cd "$(systemctl show aeronyx-server -p WorkingDirectory --value)"
pwd

على العُقد المثبّتة باستخدام أمر Nodeboard، يطبع هذا /root/open/AeroNyx.

الأوامر في لمحة

الأمر	هل يغيّر المضيف؟	استخدمه من أجل
`./deploy/node/aeronyx-node.sh status --repo-dir "$PWD"`	لا	النظرة الأولى: حالة الخدمة، والصحة المحلية، والاكتشاف، وحالة الترقية، والخطوة التالية الموصى بها
`./deploy/node/aeronyx-node.sh health --repo-dir "$PWD" --json`	لا	تشخيصات كاملة؛ السطر الأخير بصيغة JSON
`./deploy/node/aeronyx-node.sh logs --repo-dir "$PWD" --lines 200`	لا	سجل الخدمة الحديث (`--follow` للمتابعة المستمرة)
`./deploy/node/aeronyx-node.sh relay-probe --repo-dir "$PWD" --two-hop --json`	لا يغيّر المضيف؛ يرسل مغلّفًا مشفّرًا اصطناعيًا واحدًا إلى الأقران	هل مسار المُرحِّل صالح للاستخدام؟
`./target/release/aeronyx-server relay-smoke --confirm-live-relay-smoke --json`	ينشئ جلستي اختبار قصيرتَي الأجل	إثبات شامل من طرف إلى طرف للتسليم المصادَق عليه عبر المُرحِّل
`./target/release/aeronyx-server mailbox-probe … --confirm-live-mailbox-probe --json`	ينشئ صندوق بريد واحدًا قصير الأجل على العقدة المستهدفة	إثبات شامل من طرف إلى طرف لصندوق البريد المجهول عبر مسار البصل
`./deploy/node/aeronyx-node.sh upgrade --repo-dir "$PWD" …`	نعم	البناء والتحقق من الصحة والانتقال إلى إصدار جديد مع إمكانية التراجع

الحالة

bash

./deploy/node/aeronyx-node.sh status --repo-dir "$PWD"

يطبع status بالترتيب:

systemctl status aeronyx-server (آخر 20 سطرًا)
ملخصًا لواجهة API المحلية للصحة (http://127.0.0.1:8421/api/vpn/health) وواجهة API لحالة المشغّل (http://127.0.0.1:8421/api/operator/status)
جاهزية الاكتشاف المحلي من http://127.0.0.1:8422/api/discovery/status: الإعلان عن ChatRelay ونصاب الأقران
حالة آخر عملية ترقية من /var/lib/aeronyx/upgrade-status.json
توصية للمشغّل: operator_status وoperator_title وoperator_detail وoperator_next_step

تأتي التوصية من فحص الصحة. وتكون حالتها إحدى القيم التالية:

`operator_status`	الأولوية	المعنى
`critical`	`fix_failed_healthcheck` أو `fix_failed_upgrade`	فشل أحد الفحوصات، أو فشلت آخر ترقية
`warning`	`service_not_active` أو `privacy_protocol_degraded` أو `review_warnings`	الخدمة متوقفة، أو الصحة المحلية ليست `ok`، أو توجد تحذيرات
`info`	`upgrade_staged`	يوجد إصدار مبنيّ ومُجهَّز ينتظر إعادة التشغيل
`ok`	`monitor`	لا توجد فحوصات فاشلة

الصحة

bash

./deploy/node/aeronyx-node.sh health --repo-dir "$PWD" --json

يقرأ فحص الصحة الملفات وsystemd ونقاط النهاية المحلية؛ ولا يغيّر المضيف أبدًا. يطبع كل فحص [PASS] أو [WARN] أو [FAIL]، ثم سطر [SUMMARY] pass=… warn=… fail=…، ثم سطرًا واحدًا بصيغة JSON. استخدم --json-only لطباعة JSON فقط. ينتهي الأمر بحالة خروج غير صفرية إذا فشل أي فحص.

ما الذي يفحصه: المستودع، والملف المتتبَّع Cargo.lock، والملف التنفيذي للإصدار؛ والتحقق من صحة الإعداد باستخدام aeronyx-server validate؛ وملفات التسجيل والمفاتيح؛ ووحدة systemd وسياسة إعادة التشغيل والتحصين؛ والذاكرة والقرص والمنفذين 51820 و8421؛ وتمرير IP وNAT؛ ونقطة نهاية الصحة المحلية؛ والاكتشاف؛ والنسخ الاحتياطية من الإصدارات.

حقول JSON الرئيسية:

الحقل	المعنى
`success`	`true` عندما لا يفشل أي فحص
`summary`	أعداد `pass` و`warn` و`fail`
`operator_action`	التوصية التي يعرضها `status` (`status` و`priority` و`title` و`detail` و`next_step`)
`local_vpn_health`	`status` (`ok` عندما تكون العقدة سليمة)، و`active_sessions`، و`placement_readiness`، و`encrypted_message_forwarding`
`capacity`	عدّادات السعة والمخاطر التي تُبلغ عنها العقدة
`discovery_readiness`	قدرة ChatRelay (مُعدّة، ونقطة النهاية جاهزة، ووقت التشغيل جاهز، ومُعلَن عنها، والعوائق)، و`peer_quorum` (`quorum_ready` و`valid_peers` و`healthy_peers` و`routeable_chat_relays` و`routeable_onion_middle_hops` و`next_action`)، و`network_story` (جاهزية القفزة الواحدة والقفزتين)، و`recovery_anchor`
`runtime`	إيداع Git وفرع نسخة المستودع، وما إذا كانت الملفات المتتبَّعة معدّلة، وأوقات الملف التنفيذي والإعداد، و`service_active`، و`service_enabled`، وسياسة إعادة التشغيل في systemd، وما إذا كانت الوحدة تشير إلى هذا الملف التنفيذي وهذا الإعداد، وشبكة VPN الفرعية، والنسخ الاحتياطية من الإصدارات
`upgrade_status`	آخر خطوة ترقية وحالتها ورسالتها
`checks`	كل فحص مع حالته ورسالته

يمكنك قراءة نقاط النهاية المحلية الخام مباشرة:

bash

curl -s http://127.0.0.1:8421/api/vpn/health
curl -s http://127.0.0.1:8422/api/discovery/status

السجلات

bash

./deploy/node/aeronyx-node.sh logs --repo-dir "$PWD" --lines 200
./deploy/node/aeronyx-node.sh logs --repo-dir "$PWD" --follow

يغلّف هذان الأمران journalctl -u aeronyx-server -n <lines> --no-pager (160 سطرًا افتراضيًا) وjournalctl -u aeronyx-server -f. استخدم journalctl مباشرة للنطاقات الزمنية، على سبيل المثال journalctl -u aeronyx-server --since "1 hour ago".

إثباتات المُرحِّل وصندوق البريد

تجيب هذه الأوامر عن أسئلة مختلفة. لا تعامل نجاح فحص اصطناعي على أنه إثبات للتسليم الفعلي.

relay-probe (اصطناعي)

bash

./deploy/node/aeronyx-node.sh relay-probe --repo-dir "$PWD" --json
./deploy/node/aeronyx-node.sh relay-probe --repo-dir "$PWD" --two-hop --json

يرسل مغلّف BlindRelay اصطناعيًا واحدًا عشوائيًا ومعتمًا من هذه العقدة إلى قرين ChatRelay مكتشَف، ولا يُبلغ إلا عن التغيّرات في العدّادات. يرسله --two-hop عبر قفزة وسطى إلى عقدة نهائية. تكون قيمة status في النتيجة ok أو attention أو blocked أو error، ويوضّح two_hop_readiness ما الذي ينقص عندما يتعذّر إنشاء مسار بقفزتين. يقرأ ذاكرة الأقران المؤقتة ومفتاح العقدة، لذا يحتاج إلى صلاحيات root. وهو ليس حركة مرور للمستخدمين، ولا يثبت التسليم إلى صندوق البريد. يُجري fleet-smoke فحصًا اصطناعيًا مشابهًا عبر عدة عُقد عامة تحدّدها باستخدام --endpoints.

relay-smoke (مصادَق عليه، من طرف إلى طرف)

bash

./target/release/aeronyx-server relay-smoke --confirm-live-relay-smoke --json

يعمل relay-smoke بوصفه عميلًا حقيقيًا مقابل العقدة الموجودة على هذا المضيف. يفتح جلستين قصيرتَي الأجل بهويات مؤقتة تُتلف بعد الاستخدام، ويُكمل مصافحة الإنتاج مع تثبيتها على مفتاح هذه العقدة. يرسل رسالة عشوائية واحدة بحجم 48 بايت، مشفّرة من طرف إلى طرف، عبر مسار المُرحِّل متعدد القفزات المصادَق عليه. ثم يتحقق من الإيصال النهائي الموقّع لهذا الطلب بعينه، ويسحب الرسالة من صندوق بريد هذه العقدة، ويفك تشفيرها، ويُقرّ باستلامها، ويتحقق من أن صندوق البريد فارغ وأن الجلستين مغلقتان.

يرفض البدء ما لم تنجح جميع البوابات:

البوابة	يفشل مع
الصحة المحلية `ok` ولم يفشل أي فحص صحة	`node health is not ready` / `node health has failed checks`
لدى العقدة صفر جلسات نشطة	`relay smoke requires zero active sessions for evidence attribution`
نصاب الأقران ومجمّع المسارات ومسار البصل ذو القفزتين جاهزة	`peer quorum is not ready` / `route pool is not ready` / `two-hop onion route is not ready`
يوجد مسار تسليم مصادَق عليه يضم قرينين على الأقل قادرين على إصدار إيصالات التسليم	`authenticated delivery path is not ready: <reason>`، حيث يكون السبب `no_receipt_capable_terminal` أو `no_receipt_capable_middle` أو `no_network_diverse_receipt_path`
ChatRelay مفعّل في الإعداد ووقت تشغيله جاهز	`chat relay is disabled in node configuration` / `chat relay runtime is not ready`
تحقّق تخزين الحفظ في المُرحِّل من متانة الإيداع الكاملة (SQLite `FULL` أو أقوى)	`encrypted custody durability is unavailable; restart the node with the current binary` / `… is not FULL-or-stronger`
يُبلغ الملف التنفيذي قيد التشغيل عن صحة مُرحِّل البصل المصادَق عليه	`authenticated onion relay health is unavailable; restart the node with the current binary`

ملاحظات:

يجب تشغيله بصلاحيات root على العقدة نفسها. يقرأ /etc/aeronyx/server.toml ومفتاح العقدة، ولا يقبل إلا عناوين الاسترجاع المحلي (--server، القيمة الافتراضية 127.0.0.1:51820؛ و--health-url، القيمة الافتراضية http://127.0.0.1:8421/api/vpn/health).
يضبط --timeout-seconds نافذة الإثبات: من 5 إلى 120 ثانية، والقيمة الافتراضية 30.
اشتراط صفر جلسات نشطة يعني أن العقدة التي تخدم مستخدمي VPN يجب تفريغها أولًا. فعّل وضع الصيانة في Nodeboard وانتظر حتى يصل عدد الجلسات إلى الصفر.
جلستا الاختبار جلستان حقيقيتان في البروتوكول، لذا قد تظهران لفترة وجيزة في Sessions في Nodeboard.
يتضمن الإثبات الناجح "status": "passed"، وتكون قيم terminal_receipt_observed وentry_mailbox_round_trip_verified وentry_mailbox_ack_verified وe2e_ciphertext_verified جميعها true، وتكون قيمة session_cleanup هي explicit_authenticated_close. وتكون قيمة terminal_replica_cleanup هي node_ttl_managed: فالإقرار بالاستلام على عقدة الدخول لا يحذف النسخة التي تحتفظ بها العقدة النهائية، والتي تنتهي صلاحيتها من تلقاء نفسها.
أي بوابة فاشلة أو خطأ أو حقل مفقود يعني إثباتًا فاشلًا، لا نجاحًا جزئيًا.

mailbox-probe (من جهة العميل)

bash

./target/release/aeronyx-server mailbox-probe \
  --seed http://SEED_PUBLIC_IP:8422 \
  --target <64-hex node ID of the mailbox node> \
  --entry <64-hex node ID of a different entry node> \
  --confirm-live-mailbox-probe --json

يتصرف mailbox-probe كما يتصرف التطبيق: يستخدم مفاتيح مؤقتة تُتلف بعد الاستخدام، ويبني مسار البصل الخاص به من الواصفات الموقّعة التي يجمعها من عُقد --seed، ويرسل طلبات HTTP عادية إلى واجهة API العامة للأقران في عقدة الدخول، دون جلسة VPN. ويُجري دورة الحياة الكاملة لصندوق البريد المجهول على العقدة المستهدفة: ticket_issue وlease_create وput وpull_one وack ثم pull_one أخيرًا. ويتحقق من تطابق البايتات المسحوبة ومن أن صندوق البريد فارغ بعد ذلك. يُبلغ الإثبات الناجح عن "status": "verified" وعدد القفزات.

يمكن تكرار --seed. وبدون --entry يتكون المسار من قفزة واحدة.
معرّف العقدة هو المفتاح العام للعقدة بصيغة سداسية عشرية من 64 حرفًا. على عقدة تشغّلها، يطبعه ./target/release/aeronyx-server pubkey -c /etc/aeronyx/server.toml.
يجب أن يكون صندوق البريد المجهول مفعّلًا على العقدة المستهدفة ([memchain.chat_relay.anonymous_mailbox] enabled = true)؛ وهو معطّل افتراضيًا.
يجب ألا تقل قيمة --work-bits (الافتراضية 12) عن إعداد العمل للتذاكر في العقدة المستهدفة. وتنطبق --timeout-seconds على كل طلب (الافتراضية 20).
لا يقرأ ملفات العقدة المحلية، لذا يمكن تشغيله من أي جهاز يتوفر عليه الملف التنفيذي. وهو يثبت حفظ عنصر معتم، لا أن المستلم يستطيع فك تشفيره.

الترقية بأمان

استخدم مسار الترقية، لا git pull متبوعًا بـ systemctl restart:

bash

./deploy/node/aeronyx-node.sh upgrade --repo-dir "$PWD" --build-priority live --build-jobs auto

ما الذي يفعله:

يحصل على قفل للنشر ويرفض التشغيل إذا كانت الملفات المتتبَّعة في نسخة المستودع معدّلة (--allow-dirty يتجاوز ذلك).
يسحب main (أو يبني إيداعًا محددًا بدقة في نسخة معزولة باستخدام --commit <40-hex SHA>).
يبني باستخدام سلسلة أدوات Rust المحدّدة إصدارها في المستودع. تستخدم الأولوية live (الافتراضية) و--build-jobs auto نحو نصف المعالجات حتى تواصل العقدة قيد التشغيل تقديم الخدمة.
يتحقق من صحة /etc/aeronyx/server.toml باستخدام الملف التنفيذي الجديد. لا يُستبدل ملف الإعداد أبدًا.
ينسخ احتياطيًا الملف التنفيذي الذي يعمل فعليًا إلى /var/lib/aeronyx/releases/.
يفحص الجلسات النشطة بعد البناء، ومرة أخرى قبيل إعادة التشغيل مباشرة. إذا وُجدت أي جلسات، أو إذا تعذّرت قراءة عددها أثناء عمل الخدمة، يتوقف دون تبديل الإصدارات.
يحدّث وحدات systemd، ويضع الملف التنفيذي الجديد مكان القديم، ويعيد تشغيل الخدمة.
ينتظر حتى 180 ثانية (90 فحصًا، بفاصل ثانيتين) إلى أن تُبلغ الصحة المحلية ok من الإيداع الذي بناه للتو. إذا فشلت إعادة التشغيل أو حالة الخدمة أو فحص الصحة، يستعيد الملف التنفيذي والوحدات السابقة تلقائيًا.
يحتفظ بأحدث 10 نسخ احتياطية من كل نوع ويسجّل النتيجة في /var/lib/aeronyx/upgrade-status.json.

إذا كانت لدى العقدة جلسات نشطة، يستمر البناء ثم تتوقف الترقية مع الرسالة Active sessions appeared during compilation. Enter maintenance mode, drain sessions, and run the upgrade again. فعّل وضع الصيانة من Settings في Nodeboard، وانتظر حتى يصل عدد الجلسات النشطة إلى الصفر، ثم شغّل الأمر نفسه مرة أخرى. تعيد إعادة البناء استخدام ذاكرة التخزين المؤقت.

التجهيز الآن وإعادة التشغيل لاحقًا

bash

./deploy/node/aeronyx-node.sh upgrade --repo-dir "$PWD" --no-restart

يبني --no-restart ويتحقق من الصحة وينشئ النسخة الاحتياطية، ثم يثبّت الملف التنفيذي الجديد على القرص دون إعادة التشغيل. بعد ذلك يُبلغ status عن upgrade_staged. تحتفظ العملية قيد التشغيل بالإصدار القديم. وأي إعادة تشغيل لاحقة، بما في ذلك إعادة تشغيل النظام أو إعادة التشغيل التلقائية بعد تعطّل، تشغّل الملف التنفيذي الجديد.

للانتقال خلال نافذة صيانة، فرّغ العقدة وشغّل الترقية مرة أخرى دون سحب، حتى تنتقل إلى ما جهّزته بالضبط مع فحص الجلسات وانتظار الصحة والتراجع:

bash

./deploy/node/aeronyx-node.sh upgrade --repo-dir "$PWD" --skip-pull

لا تستخدم --force. فهو يعيد التشغيل حتى عندما تكون هناك جلسات نشطة أو يكون عدد الجلسات غير معروف، ويقطع اتصال المستخدمين.

التراجع يدويًا

تتراجع الترقية تلقائيًا عندما يفشل الإصدار الجديد في البدء أو في الإبلاغ عن أنه سليم. للعودة إلى إصدار سابق في وقت لاحق، رقِّ أحد الملفات التنفيذية المحفوظة:

bash

ls -lt /var/lib/aeronyx/releases/
./deploy/node/aeronyx-node.sh promote-binary --repo-dir "$PWD" \
  --binary /var/lib/aeronyx/releases/<aeronyx-server.binary.YYYYMMDD_HHMMSS.xxxxxx>

يتحقق promote-binary من صحة الإعداد باستخدام الملف التنفيذي المختار، ويرفض التشغيل ما لم يكن عدد الجلسات النشطة صفرًا بالضبط. يطلب منك كتابة PROMOTE BINARY، وينسخ الملف التنفيذي الحالي احتياطيًا بجواره، ويبدّل الملف التنفيذي ويعيد التشغيل. إذا لم تصبح الخدمة سليمة خلال 180 ثانية، يستعيد الملف التنفيذي السابق. وهو يستبدل الملف التنفيذي فقط، لا وحدات systemd.

بعد أي إعادة تشغيل

افحص ما يلي بالترتيب:

يُعيد systemctl is-active aeronyx-server القيمة active. الوحدة من النوع Type=notify، لذا تعني active أن العملية أبلغت عن جاهزيتها؛ وقد يستغرق البدء حتى 300 ثانية قبل أن يتوقف systemd عن المحاولة.
يعرض ./deploy/node/aeronyx-node.sh status --repo-dir "$PWD" القيمة operator_status=ok، أو تحذيرًا تفهمه.
ينتهي ./deploy/node/aeronyx-node.sh health --repo-dir "$PWD" --json بـ "success":true وتكون قيمة local_vpn_health.status هي ok.
الإيداع قيد التشغيل هو الإيداع الذي قصدته: يُبلغ عنه curl -s http://127.0.0.1:8421/api/vpn/health في الحقل runtime.git_commit. (الحقل runtime.git_commit في health --json هو إيداع نسخة المستودع.)
تكون قيمة discovery_readiness.peer_quorum.quorum_ready هي true بعد جولات التناقل الأولى.
لعُقد المُرحِّل: يُبلغ relay-probe --two-hop --json عن ok.
في Nodeboard، تكون النبضة حديثة، ويعرض Rust Runtime الإصدار الجديد، وتظهر إعادة التشغيل تحت Alerts / Events. عطّل وضع الصيانة عند الانتهاء.
لا يحتوي journalctl -u aeronyx-server --since "15 min ago" على أخطاء متكررة.

كيف يظهر ذلك في Nodeboard

يتلقى Nodeboard النبضة الموقّعة للعقدة وتقارير الجلسات. ولا ينفّذ أوامر على المضيف من تلقاء نفسه؛ فالإجراءات التي تختارها هناك توضع في قائمة انتظار وتنفّذها العقدة عند نبضتها التالية.

على العقدة	في Nodeboard
حالة الخدمة والصحة المحلية	قائمة Nodes وتفاصيل العقدة: AeroNyx Health وRust Runtime وAeroNyx Service Readiness
عدّادات السعة	تفاصيل العقدة: Node Capacity وCapacity Decision (`ready` و`watch` و`blocked` و`waiting`)
جاهزية الاكتشاف والمُرحِّل	تفاصيل العقدة: Node Discovery وEncrypted Chat Relay؛ وServices للأسطول بأكمله
`upgrade-status.json`	تفاصيل العقدة: Rust Upgrade Workflow؛ وServices → Fleet Restart Readiness
التحذيرات في سجل الخدمة	تفاصيل العقدة: Recent Operational Events (منقّاة، آخر 24 ساعة)
عمليات إعادة التشغيل والاستعادة	Alerts / Events → Incident Closure (`open` و`watch` و`recovered`)
وضع الصيانة، والحد الأقصى للجلسات، وعرض النطاق، والفئة	Settings، ويُؤكَّد التطبيق عندما يعرض Policy Sync القيمة `synced`

تحتوي تفاصيل العقدة أيضًا على بطاقة Operator Runbook تتضمن أوامر health وstatus وlogs والترقية المُجهَّزة قابلة للنسخ، لمسار المستودع المكتشَف.

ما الذي تحتويه المخرجات

تطبع status وhealth وrelay-probe وrelay-smoke وmailbox-probe قيمًا مجمّعة فقط: الأعداد، والحالات، والتوقيتات، ورموز الأسباب. ولا تطبع المفاتيح الخاصة أو رموز التسجيل أو عناوين IP العامة للعملاء أو الوجهات أو محتويات DNS أو الحمولات أو النص الصريح للرسائل. سجلات الجلسات التي تتضمن مفاتيح العملاء مرئية في Nodeboard، لا في هذه المخرجات؛ راجع دليل لوحة تحكم المشغّلين Nodeboard. عندما تشارك المخرجات لطلب الدعم، شارك JSON وطابعه الزمني، لا عناوين المضيفين أو بيانات الاعتماد.

الأسئلة الشائعة

ما الأمر الذي يجب أن أشغّله أولًا عندما يبدو أن هناك خطأ ما؟

شغّل ./deploy/node/aeronyx-node.sh status --repo-dir "$PWD" بصلاحيات root. يعرض حالة الخدمة والصحة المحلية والاكتشاف والخطوة التالية الموصى بها، ولا يغيّر المضيف.

لماذا يفشل فحص الصحة مع "config missing" أو تحذيرات Git؟

على الأرجح أنك لست root، أو أنك تشير إلى المستودع الخطأ. المجلدان /etc/aeronyx و/var/lib/aeronyx مخصّصان لـ root فقط، وبدون --repo-dir يفحص السكربت /opt/aeronyx/AeroNyx بدلًا من نسخة المستودع التي تعمل منها الخدمة.

ما الفرق بين relay-probe وrelay-smoke؟

يرسل relay-probe مغلّفًا معتمًا اصطناعيًا واحدًا، ولا يُظهر إلا أن مسار المُرحِّل يقبل حركة المرور. أما relay-smoke فيعمل بوصفه عميلًا حقيقيًا: يتحقق من إيصال نهائي موقّع ومن سحب كامل من صندوق البريد والإقرار باستلام رسالة اختبار مشفّرة واحدة.

لماذا يقول relay-smoke إنه يحتاج إلى صفر جلسات نشطة؟

ينسب التغيّرات في العدّادات إلى جلسات الاختبار الخاصة به، لذا لا يعمل إلا على عقدة خاملة. فعّل وضع الصيانة في Nodeboard، وانتظر حتى يصل عدد الجلسات النشطة إلى الصفر، ثم شغّله.

هل يمكنني الترقية دون قطع اتصال المستخدمين؟

يمكنك بناء ترقية وتجهيزها باستخدام --no-restart أثناء اتصال المستخدمين. أما الانتقال إلى الإصدار الجديد فيحتاج إلى إعادة تشغيل، لذا فرّغ العقدة باستخدام وضع الصيانة ثم شغّل upgrade --skip-pull.

كيف أعود إلى الإصدار السابق؟

تتراجع الترقية الفاشلة تلقائيًا. للتراجع لاحقًا، استخدم promote-binary مع إحدى النسخ الاحتياطية في /var/lib/aeronyx/releases/؛ ويتطلب ذلك صفر جلسات نشطة، ويستعيد الملف التنفيذي السابق إذا لم يكن الملف المُرقّى سليمًا.