الاسم¶

sm-notify - إرسال إعلامات إعادة التشغيل إلى أقران NFS

موجز¶

/usr/sbin/sm-notify [-dfn] [-m دقائق] [-v اسم] [-p منفذ-الإعلام] [-P مسار]

الوصف¶

أقفال الملفات ليست جزءًا من حالة نظام الملفات المستمرة. وبالتالي تُفقد حالة القفل عند إعادة تشغيل المضيف.

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

بالنسبة لـ NFS الإصدار 2 والإصدار 3، يُستخدم بروتوكول مراقب حالة الشبكة (أو NSM اختصارًا) لإعلام أقران NFS بعمليات إعادة التشغيل. على لينكس، يشكل مكونان منفصلان في مساحة المستخدم خدمة NSM:

sm-notify

برنامج مساعد يشعر نظراء NFS بعد إعادة تشغيل النظام المحلي

rpc.statd

عفريت ينصت لإشعارات إعادة التشغيل من المضيفين الآخرين، ويدير قائمة المضيفين المراد إشعارهم عند إعادة تشغيل النظام المحلي

يقوم مدير أقفال NFS المحلي بتنبيه rpc.statd المحلي لكل نظير بعيد يجب مراقبته. عندما يعيد النظام المحلي التشغيل، يقوم أمر sm-notify بإشعار خدمة NSM على النظراء المراقبين بإعادة التشغيل. عندما يعيد نظير بعيد التشغيل، يقوم ذلك النظير بإشعار rpc.statd المحلي، والذي بدوره يمرر إشعار إعادة التشغيل إلى مدير أقفال NFS المحلي.

عملية NSM بالتفصيل¶

يؤدي أول تفاعل لقفل الملفات بين عميل وخادم NFS إلى قيام مديري أقفال NFS في كلا الطرفين بالاتصال بخدمة NSM المحلية الخاصة بهما لتخزين معلومات حول الطرف المقابل. في لينكس، يتصل مدير القفل المحلي بـ rpc.statd.

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

يرسل عميل NFS اسم مضيف، يعرف باسم المستدعِي للعميل، في كل طلب قفل ملف. يمكن لخادم NFS استخدام اسم المضيف هذا لإرسال استدعاءات GRANT غير متزامنة للعميل، أو لإشعار العميل بأنه أُعيد تشغيله.

يمكن لخادم NFS في لينكس توفير caller_name الخاص بالعميل أو عنوان شبكة العميل إلى rpc.statd. لأغراض بروتوكول NSM، يُعرف هذا الاسم أو العنوان باسم mon_name للمتراسل المراقب. بالإضافة إلى ذلك، يخبر مدير القفل المحلي rpc.statd بما يعتقد أنه اسم مضيفه الخاص. لأغراض بروتوكول NSM، يُعرف اسم المضيف هذا باسم my_name.

لا يوجد تفاعل مكافئ بين خادم NFS وعميل لإعلام العميل بـ caller_name الخاص بالخادم. لذلك، لا يعرف عملاء NFS فعليًا ما هو mon_name الذي قد يستخدمه خادم NFS في طلب SM_NOTIFY. يسجل عميل NFS في لينكس اسم المضيف للخادم المستخدم في أمر التحميل لتحديد خوادم NFS التي تعيد التشغيل.

الخيارات¶

-d

يبقي sm-notify ملحقًا بطرفيته التحكمية ويعمل في المقدمة بحيث يمكن مراقبة تقدم الإعلام مباشرة.

-f

أرسل الإعلامات حتى لو كان sm-notify قد عمل بالفعل منذ آخر إعادة تشغيل للنظام.

-m وقت-إعادة-المحاولة

يحدد طول الوقت، بالدقائق، لمواصلة إعادة محاولة الإعلامات للمضيفين غير المستجيبين. إذا لم يُحدد هذا الخيار، يحاول sm-notify إرسال الإعلامات لمدة 15 دقيقة. يؤدي تحديد القيمة 0 إلى جعل sm-notify يواصل إرسال الإعلامات إلى الأقران غير المستجيبين حتى يُقتل يدويًا.

تُعاد محاولة الإعلامات إذا فشل الإرسال، أو لم يستجب البعيد، أو لم تُسجل خدمة NSM للبعيد، أو إذا كان هناك فشل في DNS يمنع تحليل mon_name للبعيد إلى عنوان.

لا تُزال المضيفات من قائمة الإعلام حتى يُستلم رد صالح. ومع ذلك، فإن إجراء SM_NOTIFY له نتيجة فارغة. لا توجد طريقة لـ sm-notify لمعرفة ما إذا كان البعيد قد تعرف على المرسل وبدأ استرداد القفل المناسب.

-n

يمنع sm-notify من تحديث رقم حالة NSM للنظام المحلي.

-p منفذ

يحدد رقم منفذ المصدر الذي يجب أن يستخدمه sm-notify عند إرسال إعلامات إعادة التشغيل. إذا لم يُحدد هذا الخيار، يُستخدم منفذ مؤقت مختار عشوائيًا.

يمكن استخدام هذا الخيار لعبور جدار ناري بين العميل والخادم.

-P, --state-directory-path مسار_الاسم

يحدد اسم مسار الدليل الأصلي حيث توجد معلومات حالة NSM. إذا لم يُحدد هذا الخيار، يستخدم sm-notify /var/lib/nfs افتراضيًا.

بعد البدء، يحاول sm-notify تعيين UID و GID الفعليين إلى المالك والمجموعة للدليل الفرعي sm من هذا الدليل. بعد تغيير المعرفات الفعلية، يحتاج sm-notify فقط إلى الوصول إلى الملفات في sm و sm.bak داخل مسار دليل الحالة.

-v عنوان-ip | اسم-مضيف

يحدد عنوان الشبكة الذي سيُرسل منه إعلامات إعادة التشغيل، ووسيطة mon_name لاستخدامها عند إرسال طلبات SM_NOTIFY. إذا لم يُحدد هذا الخيار، يستخدم sm-notify عنوانًا بدلًا كعنوان ربط النقل، ويستخدم my_name المسجل عند مراقبة البعيد كوسيطة mon_name عند إرسال طلبات SM_NOTIFY.

يمكن التعبير عن صيغة ipaddr كعنوان عرض IPv4 أو IPv6. إذا تم استخدام صيغة ipaddr، يقوم أمر sm-notify بتحويل هذا العنوان إلى اسم مضيف لاستخدامه كوسيط mon_name عند إرسال طلبات SM_NOTIFY.

قد يكون هذا الخيار مفيدًا في التهيئات متعددة الواجهات حيث يتطلب البعيد الإخطار من عنوان شبكة محدد.

ملف الضبط¶

يمكن التحكم في العديد من الخيارات التي يمكن تعيينها في سطر الأوامر أيضًا من خلال القيم المحددة في القسم [sm-notify] أو، في حالة واحدة، القسم [statd] من ملف التهيئة /etc/nfs.conf.

تشمل القيم المعترف بها في القسم [sm-notify]: retry-time وoutgoing-port وoutgoing-addr. لهذه نفس تأثير خيارات سطر الأوامر m وp وv على التوالي.

قيمة إضافية معترف بها في القسم [sm-notify] هي lift-grace. افتراضيًا، يرفع sm-notify فترة السماح لـ lockd مبكرًا إذا لم يكن لديه مضيفين لإخطارهم. بعض تهيئات التوفر العالي تشغل مثيل sm-notify واحد لكل عنوان IP عائم. في هذه التهيئات، قد يمنع رفع فترة السماح مبكرًا العملاء من استعادة الأقفال. تعيين lift-grace إلى n يمنع sm-notify من إنهاء فترة السماح مبكرًا. لا يوجد خيار سطر أوامر مقابل لـ lift-grace.

القيمة المعترف بها في القسم [statd] هي state-directory-path.

الأمن¶

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

خلال العملية العادية، يكون معرف المستخدم الفعال الذي يختاره هو مالك دليل الحالة. يتيح له هذا الاستمرار في الوصول إلى الملفات في ذلك الدليل بعد التخلي عن صلاحيات الجذر. للتحكم في معرف المستخدم الذي يختاره rpc.statd، استخدم ببساطة chown(1) لضبط مالك دليل الحالة.

يمكن أيضًا بدء أمر sm-notify بواسطة معرف المستخدم الذي يملك دليل الحالة. هذا مفيد للحالة عندما يُستدعى من برنامج rpc-stat ha-callout الذي يعمل بالفعل كمستخدم غير مميز. لن يمتلك المستخدم غير الجذر القدرات اللازمة للتخلي عن صلاحيات الجذر كما هو موصوف أعلاه.

ملاحظات إضافية¶

استرداد القفل بعد إعادة التشغيل أمر بالغ الأهمية للحفاظ على سلامة البيانات ومنع تعليق التطبيقات غير الضروري.

لمساعدة rpc.statd في مطابقة طلبات SM_NOTIFY مع طلبات NLM، يجب مراعاة عدد من أفضل الممارسات، بما في ذلك:

يجب أن يتطابق اسم عقدة UTS لأنظمتك مع أسماء DNS التي يستخدمها متراسلو NFS للاتصال بها

يجب أن تكون أسماء عقد UTS لأنظمتك دائمًا أسماء نطاقات مؤهلة بالكامل

يجب أن تكون خرائط DNS الأمامية والعكسية لأسماء عقد UTS متسقة

يجب أن يتطابق اسم المضيف الذي يستخدمه العميل لضم (mount) الخادم مع mon_name الخاص بالخادم في طلبات SM_NOTIFY التي يرسلها

لا يؤدي فصل نظام ملفات NFS بالضرورة إلى توقف عميل NFS أو الخادم عن مراقبة بعضهما البعض. قد يستمر كلاهما في مراقبة بعضهما البعض لفترة في حال أدت حركة مرور NFS اللاحقة بينهما إلى عمليات وصل جديدة وقفل ملفات إضافي.

في لينكس، إذا جرى إلغاء تحميل وحدة النواة lockd أثناء التشغيل العادي، فإن جميع نظراء NFS البعيدين سيصبحون غير مراقبين. يمكن أن يحدث هذا في عميل NFS، على سبيل المثال، إذا قام أداة تركيب تلقائي (automounter) بإزالة جميع نقاط تركيب NFS بسبب عدم النشاط.

الملفات¶

/var/lib/nfs/sm

الدليل الذي يحتوي على قائمة المراقبة

/var/lib/nfs/sm.bak

الدليل الذي يحتوي على قائمة الإشعارات

/var/lib/nfs/state

رقم حالة NSM لهذا المضيف

/proc/sys/fs/nfs/nsm_local_state

نسخة النواة من رقم حالة NSM

انظر أيضًا¶

rpc.statd(8), nfs(5), uname(2), hostname(7)

RFC 1094 - "NFS: مواصفات بروتوكول نظام ملفات الشبكة"
RFC 1813 - "NFS الإصدار 3 مواصفات البروتوكول"
بروتوكولات OpenGroup للعمل البيني: XNFS، الإصدار 3W - الفصل 11

المؤلفون¶

Olaf Kirch <okir@suse.de>
Chuck Lever <chuck.lever@oracle.com>

ترجمة¶

تُرجمت هذه الصفحة من الدليل بواسطة زايد السعيدي <zayed.alsaidi@gmail.com>

هذه الترجمة هي وثيقة مجانية؛ راجع رخصة جنو العامة الإصدار 3 أو ما بعده للاطلاع على شروط حقوق النشر. لا توجد أي ضمانات.

إذا وجدت أي أخطاء في ترجمة صفحة الدليل هذه، يرجى إرسال بريد إلكتروني إلى قائمة بريد المترجمين: kde-l10n-ar@kde.org.