وحدة التحكم التسلسلية

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

تتصل وحدة التحكم التسلسلية في Azure بالمنفذ التسلسلي المُحاكى للعقدة عبر منصة Azure. وهي لا تجتاز مستوى التحكم في F5 Distributed Cloud، ولا مستوى البيانات للعقدة، ولا أي مسار شبكي تتحكم فيه العقدة — ولهذا السبب بالضبط تعمل عندما لا يعمل أي شيء آخر.

استخدمها عندما لا تُقلع عقدة CE أبدًا: فشل التسجيل، أو غياب الموقع عن المستأجر، أو كانت العقدة تعمل لكن دون مسار للخروج. في كل تلك الحالات لا تمتلك واجهة API للتصحيح أي نفق لتمرير الاتصال عبره. ويصمد SSH أمام فشل التسجيل، لكن فقط إذا كان مفتاحه قد كُتب بالفعل عند الإقلاع الأول وكان بإمكانك الوصول إلى العنوان الداخلي للعقدة من داخل VNet — وكلاهما غير متحقق في عقدة تقابلها للمرة الأولى.

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

الشرط المسبق: تشخيصات التشغيل

تتطلب Azure تمكين تشخيصات التشغيل على الجهاز الافتراضي قبل أن تسمح بربط وحدة تحكم تسلسلية. ويُمكِّن ذلك terraform/modules/ce-node:

boot_diagnostics {}

يؤدي الكتلة الفارغة إلى اختيار تخزين تديره Azure، لذا لا يوجد حساب تخزين للتشخيصات ولا سياسة دورة حياة ولا مفتاح وصول يجب امتلاكه. تأكد من ذلك على العقدة:

az vm show -g <resource-group> -n <vm-name> --query diagnosticsProfile

{ "bootDiagnostics": { "enabled": true } }

التمكين ليس بأثر رجعي

تلتقط تشخيصات التشغيل السجل التسلسلي عند الإقلاع. وتشغيلها لجهاز افتراضي يعمل بالفعل لا يُنتج سجلًا للإقلاع الذي حدث سابقًا، لذا يجيب az vm boot-diagnostics get-boot-log:

<Error><Code>BlobNotFound</Code><Message>The specified blob does not exist.

هذا متوقع وليس خطأً. يوجد سجل إقلاع بعد إعادة تشغيل العقدة في المرة التالية. أما الربط المباشر بوحدة التحكم فيعمل فورًا — فهو لا يعتمد على السجل.

التحقق من التوفر دون طرفية

يحتاج الربط إلى جلسة تفاعلية، لكن معرفة ما إذا كان سيتم الربط يتم عبر استدعاءي API. وكلاهما مفيد في فحص السلامة.

يجب أن تكون الخدمة مُمكَّنة للاشتراك — إذ يمكن للمسؤول تعطيلها على مستوى المستأجر بالكامل:

az rest --method get --url \
  "https://management.azure.com/subscriptions/<sub>/providers/Microsoft.SerialConsole/consoleServices/default?api-version=2018-05-01"

{ "properties": { "disabled": false } }

ثم اطلب اتصالًا بالمنفذ التسلسلي لعقدة محددة:

az rest --method post \
  --headers "Content-Type=application/json" --body '{}' --url \
  "https://management.azure.com/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Compute/virtualMachines/<vm>/providers/Microsoft.SerialConsole/serialPorts/0/connect?api-version=2018-05-01"

وجود connectionString يبدأ بـ wss:// — في هذا النشر eastus.gateway.serialconsole.azure.com — يعني أن وحدة التحكم قابلة للربط الآن. وقبل تمكين تشخيصات التشغيل، لم يكن لهذا الاستدعاء ما يرتبط به.

سلسلة الاتصال هذه هي بيانات اعتماد

إنها رمز حامل قصير العمر مُضمَّن في عنوان URL. لا تسجّله، ولا تلصقه في تذكرة دعم، ولا تودعه في مستودع. اطبع المضيف فقط عندما تعرض أن الاستدعاء نجح.

الربط

1. ثبّت الإضافة مرة واحدة:

   az extension add --name serial-console

2. اربط:

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

3. ستصل إلى محثّ تسجيل الدخول الخاص بالعقدة نفسها، وليس إلى صدفة، وذلك خلف لافتة التدقيق الخاصة بالجهاز. تُثبت وحدة التحكم التسلسلية أن القناة تعمل؛ لكنها لا تتجاوز المصادقة.

   بيانات الاعتماد التي يقبلها تسجيل الدخول التسلسلي غير متحققة

   لم يُكمل أحد تسجيل دخول عبر وحدة التحكم التسلسلية في هذا النشر، لذا لا تحدد هذه الصفحة ما يجب كتابته. الحساب admin هو حساب الجهاز الذي تكون صدفته هي Site CLI، وهو الحساب نفسه الذي يُصادق عبر وحدة تحكم الموقع بكلمة مرور — لكن لم يُظهَر أن كلمة المرور تعمل عبر تسجيل الدخول بوحدة التحكم التسلسلية، وsshd مقصور على المفاتيح فقط للحساب admin، لذا فإن المسارين ليسا — بشكل واضح — مسار بيانات الاعتماد نفسه.

مُلتقط من f5-xc-ce-vm-01، مع حذف الجزء الأوسط حيث لا يضيف مخرج وحدة systemd أي شيء:

+-----------------------------------------------+
Connected to the serial port of the VM.
If no login prompt is displayed, press ENTER.
+-----------------------------------------------+


Probing EDD (edd=off to disable)... ok
Memory KASLR using RDRAND RDTSC...
init_cea_offsets KASLR using RDRAND RDTSC...
Poking KASLR using RDRAND RDTSC...

Welcome to Red Hat Enterprise Linux 9.2024.6.3 (Plow) dracut-057-44.git20230822.el9 (Initramfs)!

[  OK  ] Started Dispatch Password …ts to Console Directory Watch.

... [320 lines of systemd unit output elided]

[  OK  ] Started Serial Getty on ttyS0.
[  OK  ] Reached target Login Prompts.
[  OK  ] Started OpenSSH server daemon.
[  OK  ] Started Container Runtime Interface for OCI (CRI-O).
[   19.960784] cloud-init[1311]: Cloud-init v. 23.1.1-12.el9_3 running 'modules:config' at Sun, 26 Jul 2026 13:13:54 +0000. Up 19.84 seconds.
[  OK  ] Finished Apply the settings specified in cloud-config.
         Starting Execute cloud user/final scripts...
[  OK  ] Started Docker Application Container Engine.
         Starting Argo Watch service...
         Starting VP Manager image load...
[  OK  ] Started Argo Watch service.
[   21.544663] cloud-init[1512]: Cloud-init v. 23.1.1-12.el9_3 running 'modules:final' at Sun, 26 Jul 2026 13:13:56 +0000. Up 21.41 seconds.
[   22.751629] cloud-init[1512]: Cloud-init v. 23.1.1-12.el9_3 finished at Sun, 26 Jul 2026 13:13:57 +0000. Datasource DataSourceAzure [seed=/var/lib/waagent].  Up 22.37 seconds
[  OK  ] Finished Execute cloud user/final scripts.
[  OK  ] Started libcontainer conta…f4b59f3b96c31ee10cd95f6eb371c.


UNAUTHORIZED ACCESS TO THIS DEVICE IS PROHIBITED
All actions performed on this device are audited
f5-xc-ce-vm-01 login: [  123.107074] Warning: Deprecated Driver is detected: iptables will not be maintained in a future major release and may be disabled
[  123.144641] Warning: Deprecated Driver is detected: ip6tables will not be maintained in a future major release and may be disabled

هناك أربعة أمور في ذلك النص جديرة بالملاحظة، لأنها تجيب على أسئلة لا تستطيع واجهة API للتصحيح الإجابة عنها:

• اكتمال cloud-init — Datasource DataSourceAzure، انتهى عند 22.37 ثانية. العقدة التي لا تُسجَّل أبدًا تفشل عادة هنا، وهنا حيث ترى ذلك.
• بدء تشغيل بيئتَي تشغيل الحاويات. كل من Container Runtime Interface for OCI (CRI-O) وDocker Application Container Engine بحالة [ OK ]، وهو الدليل عند الإقلاع على سلوك بيئة التشغيل المزدوجة الذي يفاجئ الناس في crictl وdocker.
• VP Manager image load وArgo Watch service — بدء تشغيل vpm وArgo.
• المحثّ هو محثّ العقدة نفسها، خلف لافتة التدقيق الخاصة بها. وحدة التحكم التسلسلية توصلك إلى محثّ تسجيل دخول، وليس إلى جلسة.

الربط التفاعلي يحتاج إلى طرفية حقيقية — لكن يمكن كتابته في سكربت

يضع az serial-console connect الطرفية في الوضع الخام، لذا لا يمكن تشغيله من خط أنابيب أو من أي سياق بلا TTY. ويفشل من جهة العميل، قبل الاتصال بـ Azure:

ERROR: (19, 'Operation not supported by device')
  File ".../azext_serialconsole/custom.py", line 633, in connect_serialconsole
    GV.serial_console_instance.launch_console()

هذا التتبع يتعلق بمعالجة الطرفية، وليس انقطاعًا في وحدة التحكم التسلسلية.

أما الربط نفسه، فهو قابل للأتمتة — قُد الـ websocket مباشرة بدلًا من استخدام واجهة سطر الأوامر. وقد التُقط النص أعلاه بهذه الطريقة، دون TTY. راجع scripts/serial_console_capture.py، وهي الطريقة التي ستجمع بها أدلة الإقلاع من عقدة فشلت في التسجيل دون وجود شخص جالس أمام طرفية.

توقّع إعادة المحاولة: تعتبر البوابة ترفض ما يقارب محاولة من كل اثنتين

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

[close] code=1011 reason=Connection not trusted

السلوك المرصود: تنجح بشكل متقطع، وتحت الاستخدام المستمر ترفض كل عقدة في مجموعة الموارد — بما في ذلك العقد التي كانت تعمل قبل دقائق. يعيد scripts/serial_console_capture.py المحاولة افتراضيًا لأن إعادة المحاولة تنجح كثيرًا.

السبب غير مُثبَت. وما استُبعد، لأن كل واحد منها تخمين معقول يهدر الوقت:

ليس هذا	كيفية التأكد
تقييد ARM/compute	ذلك يُرجع HTTP 429 على استدعاءات ARM. أما هذا فهو إغلاق websocket على قناة بيانات منفصلة.
اعتراض TLS بواسطة وكيل	openssl s_client -connect <region>.gateway.serialconsole.azure.com:443 | openssl x509 -noout -issuer. وجود مُصدِر أصلي O=Microsoft Corporation يستبعد ذلك؛ ووجود مورّد وكيل كمُصدِر يؤكده، والحل هو إضافة *.serialconsole.azure.com إلى قائمة السماح.
تعطيل تشخيصات التشغيل	az vm show -g <rg> -n <vm> --query diagnosticsProfile يُبلّغ عن enabled: true.
عدم تطابق الرمز بين المنح والتحدي	استخدام رمز واحد للاثنين هو الممارسة الصحيحة، لكنه لا يمنع الإغلاق.

أما ما هو سلوك موثَّق في Azure: جلسة وحدة تحكم تسلسلية واحدة لكل جهاز افتراضي، والطلب الناجح الثاني يطرد الأول. يُقطع اتصال المستخدم المطرود لكن لا يُخرج من النظام، لذا تبقى جلسة الصدفة قائمة. وشخصان يصححان عقدة واحدة سيطردان أحدهما الآخر بشكل متكرر.

للأعمال الجماعية، فضّل واجهة API للتصحيح أو SSH، فكلاهما لا تنطبق عليه هذه القيود. وSSH بشكل خاص لا يفرض حدًّا على اللصق ولا قيدًا على الجلسة الواحدة، لذا فهو الخيار الأفضل كلما كانت العقدة قابلة للوصول من داخل VNet.

اللصق محدود بـ 2,048 حرفًا

تحدّ Azure طول اللصق في وحدة التحكم التسلسلية بـ 2,048 حرفًا، لتجنّب إرهاق المنفذ التسلسلي. وإرسال أمر طويل — أو دفعة من الأوامر في عملية كتابة واحدة — يفشل بطريقة تُقرأ كتعليق أو تقييد بدلًا من كونها حدًّا على الطول.

أرسل الأوامر فرادى. هذا قيد حقيقي على أي جمع جماعي للبيانات عبر وحدة التحكم التسلسلية، وسبب آخر لتفضيل واجهة API للتصحيح لهذا العمل.

ما يمكنك رؤيته هنا وما لا تستطيع واجهة API إظهاره

• cloud-init أثناء تشغيله، أو فشله، أو عدم بدئه أبدًا — السبب المعتاد لعقدة لا تُسجَّل أبدًا.
• محاولات التسجيل مقابل register.ves.volterra.io، بما في ذلك خطأ في التكوين أو رمز رفضه المستأجر.
• رسائل النواة والإقلاع من قبل تشغيل أي وكيل.
• العقدة عندما لا يوجد لها مسار شبكي عامل، وهو ما يُبطل كل مسار آخر.

أما للعقدة التي تكون ONLINE، فضّل واجهة API للتصحيح: فهي قابلة للكتابة في سكربتات، وتنتج أدلة يمكنك إعادة تشغيلها، ولا تشغل المنفذ التسلسلي الوحيد.