ردّ نظام التشغيل بالرمز 231، وظل النص البرمجي مديناً بإيصال انتهاء: RFC 3179

الخلاصة

• وضع RFC 3179 بروتوكولاً صغيراً بين Script MIB في وكيل SNMP وبين بيئات التشغيل الخاصة بكل لغة. كان الرد 231 يثبت أن النسخة وصلت إلى حالة التشغيل أو التعليق أو الاستئناف، لا أنها أكملت مهمتها.
• خُصصت رسائل مختلفة للنتائج الوسيطة والأخطاء القاتلة وغير القاتلة والانتهاء والسجل المحتفظ به. اختزالها في خانة «نجاح» واحدة يمحو التسلسل اللازم لفهم ما حدث فعلاً.
• لا يكفي انتهاء نظيف ولا نتيجة مخزنة لإثبات الأثر. على المستدعي تفسير وحدات النتيجة، وعلى مراقبة مستقلة أن تتحقق من الحالة النهائية للمورد المُدار.

حدود المعرفة بين الوكيل وبيئة التشغيل

صدر RFC 3179 في أكتوبر 2001 وشرح الإصدار 1.1 من Script MIB Extensibility Protocol، المعروف اختصاراً باسم SMX. صُنفت الوثيقة «تجريبية»، ونصت على أنها لا تحدد معياراً للإنترنت. لذلك تثبت الوثيقة تصميم آلية ورسائلها، لكنها لا تثبت انتشارها أو توافق منتجات بعينها أو نجاحها لدى مشغل معروف.

جاورت الوثيقة RFC 3165، الذي عرّف Script MIB. أتاحت تلك الواجهة لمدير SNMP تثبيت نصوص برمجية وإرسال المعاملات وتشغيل النسخ والتحكم فيها وجمع نتائجها من دون ربط الواجهة بلغة محددة. عالج SMX طبقة أخرى: ليس مطلوباً من الوكيل أن يحتوي كل مفسر أو آلة افتراضية. يمكن لبيئة Java أو Tcl أو غيرهما أن تعمل في عملية مستقلة وتتخاطب مع الوكيل بلغة مشتركة.

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

تبدأ العلاقة بإنشاء الاتصال وتبادل hello، ثم تنقل أوامر مثل start وsuspend وresume وabort وstatus. قسمت الرموز ذات الأرقام الثلاثة الردود إلى نجاح وفشل وإشعارات غير متزامنة. لم تكن الأرقام اختصاراً لحكم شامل؛ كانت طريقة دقيقة لتسمية انتقال معين ومنتجه.

ماذا أثبت 231 تحديداً؟

عند تلقي start، تفحص بيئة التشغيل صياغة الطلب والنص البرمجي وملف الحماية. إذا أمكن المتابعة، تنشئ نسخة عاملة وترسل 231 بعد بلوغ حالة running. وإذا كان البدء قيد المعالجة، تنتظر الإجابة حتى الوصول إلى تلك الحالة. أما الفشل فيتخذ رمزاً مختلفاً.

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

يحافظ كل أمر آخر على النطاق نفسه. يأتي 231 في suspend بعد الانتقال إلى حالة التعليق أو لتأكيد أن الحالة موجودة سلفاً. ويأتي في resume بعد العودة إلى running أو لتأكيد استمرارها. يصف status الحالة المرصودة. أما abort فيستخدم 232 بعد الإجهاض، بما في ذلك الحالة التي يكون فيها النص مجهضاً أصلاً. كل رد يغلق عملية تحكم، لا الغرض الخارجي الذي دفع إلى طلبها.

الميل الحديث إلى لوحة ذات لون واحد يطمس الفرق. يتحول «مقبول» و«بدأ» و«يعمل» و«انتهى» و«أحدث الأثر» إلى درجات من الأخضر. يعرض SMX بديلاً أضيق وأكثر صدقاً: لكل إيصال مُصدر وأمر وانتقال، وما يقع بعد ذلك يحتاج دليلاً أحدث.

النتيجة الوسيطة ليست خط النهاية

خصّص الإصدار 1.1 مفردات للأدلة غير المتزامنة. يحمل 532 نتيجة وسيطة. ويحمل 533 نتيجة وسيطة مع طلب إصدار إشعار smScriptResult عبر Script MIB. وبذلك لا يتطابق انتقال البيانات داخل اتصال الوكيل مع وصولها إلى سطح الإدارة الأوسع.

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

يضيف RFC 3165 قيداً دلالياً: المعاملات المباشرة والنتيجة المباشرة الوحيدة قيم من نوع OCTET STRING. المستدعي هو المسؤول عن معرفة بنيتها ومعناها. يمكن للنص أن يعرض نتيجة مركبة عبر MIB أخرى أو أن يعيد عنوان URL لحمولة كبيرة. استلام العنوان يثبت المرجع فقط؛ لا يثبت التنزيل، والتنزيل لا يثبت صحة الفهم.

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

قد يظهر الخطأ ويستمر التنفيذ

يبلغ 536 عن خطأ. ويبلغ 537 عن خطأ مع طلب إشعار smScriptException. وقد يكون الخطأ في الحالتين قاتلاً أو غير قاتل. يسمح النوع الثاني للنص بالاستمرار، بينما ينهي النوع الأول التنفيذ ويتبعه ردّ الانتهاء.

لذلك توجد ثلاثة أسئلة مستقلة: هل وقع خطأ؟ هل عُرض على واجهة الإدارة الأوسع؟ هل أنهى النسخة العاملة؟ لا يجيب سجل واحد عن الأسئلة كلها. وقد يضيع الإشعار من غير أن تتغير الحالة الحقيقية في البيئة. ترتيب الأحداث ومصدرها أهم من مجرد ظهور كلمة «خطأ».

أضاف الإصدار 1.1 الرمز 538 لإعلان انتهاء النص الجاري، وأوقف الاعتماد على 534 للانتهاء العادي و535 للانتهاء غير العادي. أصبحت النتيجة أو المشكلة تسافر في رسالتها الخاصة، ثم يأتي حدث نهائي واضح. بذلك لم يعد على رمز واحد أن يحمل الإخراج وسبب الفشل ودورة الحياة معاً.

ومع ذلك لا يمثل 538 حكماً على القيمة. إنه يثبت أن بيئة التشغيل عدّت النسخة منتهية. يحتاج تقييم هذا الانتهاء إلى النتيجة أو الخطأ والمعاملات وهوية الشفرة ومعنى البيانات. أما إثبات الأثر فيحتاج قراءة من الهدف نفسه: إعداداً معتمداً أو عدادات أو قابلية وصول أو سلوك حركة أو شرطاً آخر يناسب المهمة.

الصلاحية المحدودة لا تضمن صحة الحساب

غيّر التنفيذ المفوض موضع السلطة. اقترح RFC 3179 ربط مالك الإطلاق بملف حماية في نظام التشغيل وآخر في بيئة التشغيل. يستطيع النظام إنشاء عملية مقيدة، ويستطيع المفسر أو الجهاز الافتراضي فرض حدود تخص اللغة. هذه وسائل حقيقية لتقليل ما يمكن للشفرة المختارة عن بعد أن تلمسه.

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

كان التخزين المحلي نقطة عهدة أخرى. حذرت الوثيقة من أن الكتابة في مساحة النصوص يجب أن تقتصر على وكيل SNMP؛ وإلا تمكن طرف آخر من استبدال الشفرة وتشغيلها بامتيازات خاصة. لذلك لا يكفي الاسم الإداري المألوف. ينبغي ربطه بالوحدات الفعلية التي نُفذت.

وتغير النقل للسبب نفسه. أبقى SMX 1.1 على TCP وأضاف قناة محلية ثنائية الاتجاه بوصفها الخيار المفضل. كان الإصدار السابق يمرر سراً مشتركاً في متغير بيئة تابع لنظام التشغيل، وهو خطر كشف. أزالت القناة ذلك الأسلوب المحدد، لكنها لم تجعل بقية المسار موثوقاً تلقائياً. ما زالت أذونات الملفات وهوية العملية وعهدة الأطراف وقرار وصول SNMP مسائل منفصلة.

توفر وثائق SNMPv3 اللاحقة عن المعمارية والحماية القائمة على المستخدم والتحكم القائم على المشاهد سياقاً مفيداً. لكنها لا تثبت أن اتصال SMX معين استخدمها، أو أن المتصل مخول بإطلاق النص، أو أن الإجراء اللاحق بقي داخل المشهد المسموح. حماية النقل وسلطة البدء وأثر المهمة ليست اسماً واحداً للأمر نفسه.

سجل متعدد الإيصالات بدلاً من خانة نجاح

تبدأ المراجعة قبل 231. تسجل وحدات النص أو نسخته الثابتة، والمالك، والمعاملات، والهدف، وملفات الحماية المطلوبة، ووقت الإطلاق. ثم تحفظ معرّف النسخة والرد الذي أثبت running. وتحتفظ بالترتيب الكامل لكل 532 أو 533، ولكل 536 أو 537 مع صفة القتل، ثم 538. وبعد ذلك تربط صف التاريخ بما جمعه المستدعي فعلاً.

تأتي مرحلة الفهم بعد الجمع. يصرح المستهلك بمعنى OCTET STRING ونسخة المخطط والنص التي تجعل ذلك المعنى صالحاً. إن كانت النتيجة URL، يفرق السجل بين استلام المرجع واسترجاع الجسم وتفسيره. وإن كان متوقعاً إشعار SNMP، يفرق بين توليده وتسليمه إلى مستقبل.

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

تكمن أهمية RFC 3179 في هذا الإيقاع المتدرج. لم يقل إن تشغيل النصوص يجعل الإدارة معصومة. خصص رسائل لمعالجة الطلب والحالة والإخراج الوسيط والخطأ والانتهاء، وتوقف عند حدود بيئة التشغيل. تصبح الأتمتة قابلة للمساءلة عندما يثبت كل إيصال انتقالاً واحداً ولا يتحول إلى ادعاء عن أثر لم يره.

المصادر وحدود الاستدلال

يوثق نص RFC 3179 وسجل RFC Editor ونسخة HTML وسجل IETF التاريخي وبحث التصويبات البروتوكول وحالته وإجراءاته ورسائله ونقله واعتباراته الأمنية. ويأتي نموذج Script MIB ومعنى النتائج وتاريخ التنفيذ من نص RFC 3165 وسجله ونسخة HTML. ويحد نص RFC 2593 وسجله المقارنة مع الإصدار السابق.

يوفر إطار SNMP المعماري ونموذج الحماية القائم على المستخدم ونموذج التحكم القائم على المشاهد سياقاً لاحقاً. ويسترشد الفصل التحليلي بين الأمر والحالة والدليل والأثر بمقالات Lu Heng عن أولوية الشفرة العاملة وطبقات الواقع والحد الأدنى للمواصفة الأولية. جُمّدت مجموعة المصادر الستة عشر في 2 أكتوبر 2026 بتوقيت شنغهاي.

تثبت هذه السجلات التصميم والحالة، لا الاستخدام ولا النتيجة. لا تسمي تنفيذاً حالياً أو مشغلاً أو جهازاً أو نصاً أو ملف حماية أو هجوماً أو معدل أخطاء أو وفراً في العمل أو تغييراً في الشبكة أو أثراً في الخدمة. تُقرأ الرموز داخل انتقالاتها المحددة فقط. أما تحليل سلسلة الأدلة فهو قراءة تحريرية لـ Sofia Ren، وليس قولاً من مؤلفي الوثائق أو المؤسسات المذكورة.