موقع لم يتصل بالإنترنت مطلقًا

تم الالتقاط في 2026-07-28 من أحد أجهزة CE في هذا النشر. يسجّل sitecli/capture-manifest.json أي عقدة، ويعيد scripts/capture-sitecli.sh --check التحقق من سطح الأوامر مقابل CE حي.

لا تستطيع واجهة API تصحيح هذا

تصل واجهة API الخاصة بالتصحيح إلى العقدة عبر مستوى التحكم في F5 Distributed Cloud، من خلال النفق الذي ينشئه التسجيل. إذا فشل التسجيل فلا يوجد نفق، لذا فإن كل أمر في هذا الموقع غير متاح لهذا العطل تحديدًا. اعمل من Site Console إذا كان للعقدة مسار شبكي بعد، ومن serial console إذا لم يكن كذلك.

1. تأكد من أنك تسأل المستأجر الصحيح. يكلّف هذا أمرًا واحدًا وهو الأول لأن الخطأ فيه يجعل كل خطوة لاحقة تكذب عليك: فأسطول سليم في المستأجر الذي لا تنظر إليه لا يمكن تمييزه عن أسطول لم يُسجَّل مطلقًا.

   cd terraform
   terraform output -raw xc_tenant       # the tenant this deployment belongs to
   terraform output -raw xc_env_tenant   # the tenant your shell is exporting

   f5-sales-demo
   f5-sales-demo

   غير متطابقين، أو بيانات اعتماد تعتقد أنها صحيحة تُرجع 401 مجردًا؟ ذلك هو عَرَض رمز مميز صُدر لمستأجر آخر، وقد كلّف هذا النشر بالفعل عملية إعادة بناء كاملة (issue 696).

2. تأكد مما يعتقده المستأجر. الغياب عن قائمة المواقع مشكلة مختلفة عن الوجود دون حالة ONLINE.

   curl -sS -H "Authorization: APIToken $XCSH_API_TOKEN" \
     "$XCSH_API_URL/api/config/namespaces/system/sites" | jq -r '.items[].name'

   إذا كان الموقع موجودًا ويُبلغ عن ONLINE، فقد نجح التسجيل وأنت في سير العمل الخاطئ.

3. اعثر على تسجيل الموقع وحالته. يمكن للعقدة أن تسجّل ثم تنتظر الموافقة، وهو ما يبدو مطابقًا للفشل من الخارج.

   curl -sS -H "Authorization: APIToken $XCSH_API_TOKEN" \
     "$XCSH_API_URL/api/register/namespaces/system/registrations_by_site/<site>" \
     | jq -r '.items[] | "\(.name)  \(.object.status.current_state)  \(.object.spec.gc_spec.infra.hostname)"'

   r-a97e20c8-b7e1-483d-bd76-34a64ff8bc78  ONLINE  f5-xc-ce-vm-01

   عدم وجود أي عناصر على الإطلاق يعني أن العقدة لم تُسجَّل بعد — انتقل إلى وحدة التحكم التسلسلية. أما وجود عنصر في حالة غير ONLINE فيعني أنها سجّلت وأن شيئًا بعد ذلك قد فشل، وهو تحقيق مختلف.

   لمسح مساحة الأسماء بأكملها بحثًا عن أي شيء ينتظر الموافقة، يأخذ listregistrationsbystate الحالة كـ جسم POST:

   curl -sS -X POST -H "Authorization: APIToken $XCSH_API_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{"namespace":"system","state":"PENDING"}' \
     "$XCSH_API_URL/api/register/namespaces/system/listregistrationsbystate" | jq -r '.items[].name'

   في أسطول سليم لا يُرجع ذلك شيئًا، لأن الموافقة مؤتمتة.

4. تأكد من أن الجهاز الافتراضي يعمل فعلًا، قبل افتراض وجود عطل برمجي.

   az vm list -d -g <resource-group> --query "[].{name:name,power:powerState}" -o table

   Name              Power
   ----------------  ----------
   f5-xc-ce-vm-01    VM running
   f5-xc-ce-vm-02    VM running
   f5-xc-ce-vm-03    VM running
   mcn-ce-ha-client  VM running

5. أرفق وحدة التحكم التسلسلية. يحتاج ذلك تفاعليًا إلى طرفية حقيقية؛ ويمكن بدلًا من ذلك كتابة سكربت لعملية الإرفاق نفسها عبر websocket — راجع serial console.

   az serial-console connect -g <resource-group> -n <vm-name>

   إذا رفض، تحقق من تمكين تشخيصات الإقلاع على الجهاز الافتراضي قبل استنتاج أن العقدة غير قابلة للوصول؛ فذلك المتطلب المسبق وأنماط فشله مشروحان في صفحة serial console.

6. اقرأ ما تعرضه وحدة التحكم، بهذا الترتيب. cloud-init أولًا — فالعقدة التي لم يكتمل فيها cloud-init ليس لديها تكوين تسجّل به. ثم محاولات التسجيل نفسها، ثم DNS: إذا لم تستطع العقدة تحليل register.ves.volterra.io، فلا شيء لاحق يمكن أن يعمل.

7. بمجرد أن تصبح العقدة ONLINE، تحقق باستخدام health وتوقّع state: PROVISIONED.

يُسمّى التسجيل باسم UUID، وليس أبدًا باسم موقعه

تُسمّى التسجيلات r-<uuid>، ولا توجد أي نقطة نهاية تقبل اسم موقع حيث يُتوقع اسم تسجيل. يُرجع GET .../registrations/<site> رمز 404، وهو ما يُقرأ على أنه “هذا الموقع ليس له تسجيل” بينما هو في الحقيقة “هذا ليس اسم تسجيل”. لا يأتي ربط الموقع بالتسجيل إلا من registrations_by_site/<site>، كما في الخطوة 3، أو بسرد registrations والمطابقة على gc_spec.passport.cluster_name.

الفخ نفسه جعل الأمر يبدو وكأن أسطولًا سليمًا ليس لديه أي تسجيلات.

الأسباب المعتادة

• أنت موجّه إلى المستأجر الخاطئ، فيبدو أسطول سليم وكأنه غائب. الخطوة 1.
• لم يكتمل cloud-init، لذا فإن /etc/vpm/config.yaml غائب أو خاطئ.
• رمز التسجيل منتهي الصلاحية، أو مُستهلك بالفعل، أو من مستأجر آخر.
• لا يوجد مسار خروج إلى register.ves.volterra.io.
• انحراف في الساعة كبير بما يكفي لإبطال الشهادات — يسهل استبعاده لاحقًا باستخدام chronyc-sources، لكنه غير قابل للوصول حتى تصبح العقدة متصلة. تُبلغ لافتة تسجيل الدخول عبر SSH عن NTP: Synced وحالة المحلل قبل أن تشغّل أي شيء، عندما يكون SSH متاحًا.