نام (NAME)

statd, rpc.statd - دیمن پایش و اعلان وضعیت قفلهای فایل NSM در NFS

خلاصه دستور (SYNOPSIS)

rpc.statd [-dh?FLNvV] [-H prog] [-n my-name] [-o outgoing-port] [-p listener-port] [-P path] [--nlm-port port] [--nlm-udp-port port]

توضیحات (DESCRIPTION)

دیمن rpc.statd پروتکل پایش وضعیت شبکه (NSM) را پیادهسازی کرده و هنگام راهاندازی مجدد سرور یا کلاینت NFS قفلهای پرونده را بازیابی میکند.

قفل‌های فایل بخشی از وضعیت ماندگار سیستم فایل نیستند. بنابراین هنگام راه‌اندازی مجدد یک میزبان، وضعیت قفل‌ها از دست می‌رود.

سیستم‌های فایل شبکه‌ای همچنین باید تشخیص دهند چه زمانی وضعیت قفل به دلیل راه‌اندازی مجدد یک میزبان راه دور از بین رفته است. پس از راه‌اندازی مجدد یک کلاینت NFS، سرور NFS باید تمامی قفل‌های پرونده نگه‌داشته‌شده توسط برنامه‌های در حال اجرا روی آن کلاینت را آزاد کند. پس از راه‌اندازی مجدد یک سرور، کلاینت باید قفل‌های پرونده نگه‌داشته‌شده توسط برنامه‌های در حال اجرا روی آن کلاینت را به سرور یادآوری کند.

برای NFS نسخه ۲ [RFC1094] و NFS نسخه ۳ [RFC1813]، از پروتکل Network Status Monitor (یا به اختصار NSM) برای اعلان راه‌اندازی مجدد به همتایان NFS استفاده می‌شود. در لینوکس، دو مولفه مجزا در فضای کاربری سرویس NSM را تشکیل می‌دهند:

rpc.statd: دیمنی که به اعلان‌های راه‌اندازی مجدد از سوی سایر میزبان‌ها گوش فرا می‌دهد و فهرست میزبان‌هایی را که باید هنگام راه‌اندازی مجدد سیستم محلی مطلع شوند، مدیریت می‌کند.
sm-notify: یک برنامه کمکی که پس از راه‌اندازی مجدد سیستم محلی، به همتایان NFS اطلاع‌رسانی می‌کند.

مدیر قفل NFS محلی، rpc.statd محلی خود را از هر همتای راه دور که باید پایش شود مطلع می‌سازد. هنگامی که سیستم محلی مجدداً راه‌اندازی می‌شود، دستور sm-notify راه‌اندازی مجدد را به سرویس NSM در همتایان تحت پایش اطلاع می‌دهد. هنگامی که یک میزبان راه دور راه‌اندازی مجدد می‌شود، آن همتا به rpc.statd محلی اطلاع می‌دهد که به نوبه خود این اعلان راه‌اندازی مجدد را به مدیر قفل NFS محلی بازمی‌گرداند.

جزئیات عملکرد NSM (NSM OPERATION IN DETAIL)

نخستین تعامل قفل‌گذاری پرونده میان کلاینت و سرور NFS باعث می‌شود که مدیران قفل NFS در هر دو همتا با سرویس NSM محلی خود تماس بگیرند تا اطلاعات مربوط به همتای مقابل را ذخیره کنند. در لینوکس، مدیر قفل محلی با rpc.statd تماس برقرار می‌کند.

rpc.statd اطلاعات مربوط به هر همتای تحت پایش NFS را در حافظه ماندگار ذخیره می‌کند. این اطلاعات نحوه تماس با همتای راه دور در صورت راه‌اندازی مجدد سیستم محلی، نحوه شناسایی اینکه کدام همتای تحت پایش گزارش راه‌اندازی مجدد را می‌دهد، و نحوه اطلاع‌رسانی به مدیر قفل محلی هنگامی که یک همتای تحت پایش نشان می‌دهد راه‌اندازی مجدد شده است را توصیف می‌کند.

یک کلاینت NFS در هر درخواست قفل پرونده، یک نام میزبان موسوم به caller_name کلاینت ارسال می‌کند. سرور NFS می‌تواند از این نام میزبان برای ارسال فراخوانی‌های ناهمگام GRANT به یک کلاینت یا برای اطلاع‌رسانی به کلاینت مبنی بر راه‌اندازی مجدد خود استفاده کند.

سرور NFS لینوکس می‌تواند caller_name کلاینت یا آدرس شبکه کلاینت را به rpc.statd ارائه دهد. برای اهداف پروتکل NSM، این نام یا آدرس به عنوان mon_name همتای تحت پایش شناخته می‌شود. علاوه بر این، مدیر قفل محلی به rpc.statd می‌گوید که نام میزبان خودش چیست. برای اهداف پروتکل NSM، این نام میزبان به عنوان my_name شناخته می‌شود.

هیچ تعامل معادلی میان سرور و کلاینت NFS برای آگاه ساختن کلاینت از caller_name سرور وجود ندارد. بنابراین کلاینت‌های NFS در واقع نمی‌دانند که سرور NFS ممکن است از چه mon_name در یک درخواست SM_NOTIFY استفاده کند. کلاینت NFS لینوکس از نام میزبان سرور برگرفته از دستور mount برای شناسایی سرورهای NFS در حال راه‌اندازی مجدد استفاده می‌کند.

اعلان راه‌اندازی مجدد (Reboot notification)

هنگامی که سیستم محلی مجدداً راه‌اندازی می‌شود، دستور sm-notify فهرست همتایان تحت پایش را از حافظه ماندگار خوانده و یک درخواست SM_NOTIFY به سرویس NSM در هر همتای راه دور فهرست‌شده ارسال می‌کند. این دستور از رشته mon_name به عنوان مقصد استفاده می‌کند. برای شناسایی اینکه کدام میزبان مجدداً راه‌اندازی شده است، دستور sm-notify رشته my_name ثبت‌شده در هنگام پایش آن میزبان راه دور را ارسال می‌کند. rpc.statd راه دور، درخواست‌های ورودی SM_NOTIFY را با استفاده از این رشته، یا آدرس شبکه فراخوان‌کننده، با یک یا چند همتا در فهرست پایش خود مطابقت می‌دهد.

اگر rpc.statd همتایی را در فهرست پایش خود نیابد که با درخواست ورودی SM_NOTIFY مطابقت داشته باشد، اعلان به مدیر قفل محلی ارسال نمی‌شود. علاوه بر این، هر همتا شماره وضعیت NSM خاص خود را دارد؛ یک عدد صحیح ۳۲ بیتی که پس از هر بار راه‌اندازی مجدد توسط دستور sm-notify افزایش می‌یابد. rpc.statd از این عدد برای تمایز میان راه‌اندازی‌های مجدد واقعی و اعلان‌های تکراری بازپخش‌شده استفاده می‌کند.

بخشی از بازیابی قفل NFS، کشف مجدد این است که کدام همتایان باید دوباره پایش شوند. دستور sm-notify پس از هر بار راه‌اندازی مجدد، فهرست پایش را در حافظه ماندگار پاک می‌کند.

گزینه‌ها (OPTIONS)

-d, --no-syslog: باعث می‌شود rpc.statd پیام‌های لاگ را به جای لاگ سیستم در stderr بنویسد، البته در صورتی که گزینه -F نیز مشخص شده باشد.
-F, --foreground: برنامه rpc.statd را به ترمینال کنترلی متصل نگه می‌دارد تا عملیات NSM بتواند مستقیماً پایش شود یا تحت یک دیباگر اجرا گردد. اگر این گزینه مشخص نشود، rpc.statd اندکی پس از شروع، خود را به پس‌زمینه می‌برد.
-h, -?, --help: باعث می‌شود rpc.statd اطلاعات نحوه استفاده را در stderr نمایش داده و خارج شود.
-H, --ha-callout prog: یک برنامه فراخوانی دسترسی‌پذیری بالا (high availability callout) را مشخص می‌کند. اگر این گزینه مشخص نشود، هیچ فراخوانی انجام نمی‌شود. برای جزئیات به بخش فراخوانی‌های دسترسی‌پذیری بالا در زیر مراجعه کنید.
-L, --no-notify: از اجرای دستور sm-notify توسط rpc.statd هنگام شروع به کار جلوگیری می‌کند و شماره وضعیت موجود NSM و فهرست پایش را حفظ می‌نماید.

: نکته: دستور sm-notify حاوی بررسی خاصی است تا اطمینان حاصل شود که پس از هر راه‌اندازی مجدد سیستم تنها یک بار اجرا می‌شود. این کار از اعلان‌های غیرواقعی راه‌اندازی مجدد در صورتی که rpc.statd بدون گزینه -L مجدداً راه‌اندازی شود، جلوگیری می‌کند.

-n, --name ipaddr | hostname: این رشته تنها توسط دستور sm-notify به عنوان آدرس مبدأ که درخواست‌های اعلان راه‌اندازی مجدد از آن ارسال می‌شوند، استفاده می‌شود.

: قالب ipaddr می‌تواند به صورت آدرس نمایشی IPv4 یا IPv6 بیان شود. اگر این گزینه مشخص نشود، rpc.statd از یک آدرس عمومی (wildcard) به عنوان آدرس اتصال انتقال استفاده می‌کند. برای جزئیات به sm-notify(8) مراجعه کنید.

-N: باعث می‌شود rpc.statd دستور sm-notify را اجرا کرده و سپس خارج شود. از آنجا که دستور sm-notify می‌تواند مستقیماً نیز اجرا شود، این گزینه منسوخ شده است.
-o, --outgoing-port port: شماره پورت مبدأ را مشخص می‌کند که دستور sm-notify باید هنگام ارسال اعلان‌های راه‌اندازی مجدد از آن استفاده کند. برای جزئیات به sm-notify(8) مراجعه کنید.
-p, --port port: شماره پورت مورد استفاده برای سوکت‌های شنونده RPC را مشخص می‌کند. اگر این گزینه مشخص نشود، rpc.statd تلاش می‌کند به /etc/services مراجعه کند؛ در صورت موفقیت در دریافت پورت، همان پورت را برای تمامی سوکت‌های شنونده تنظیم می‌کند، در غیر این صورت یک پورت موقت تصادفی برای هر سوکت شنونده برمی‌گزیند.

: این گزینه می‌تواند برای ثابت کردن مقدار پورت شنوندگان آن در مواقعی که درخواست‌های SM_NOTIFY باید از یک دیوار آتش بین کلاینت‌ها و سرورها عبور کنند، استفاده شود.

-T, --nlm-port port: شماره پورتی را مشخص می‌کند که lockd باید برای درخواست‌های NLM به آن گوش دهد. این گزینه هر دو پورت TCP و UDP را تنظیم می‌کند مگر اینکه پورت UDP جداگانه تنظیم شده باشد.
-U, --nlm-udp-port port: شماره پورت UDP را مشخص می‌کند که lockd باید برای درخواست‌های NLM به آن گوش فرا دهد.
-P, --state-directory-path pathname: مسیر دایرکتوری والد را که اطلاعات وضعیت NSM در آن قرار دارد مشخص می‌کند. اگر این گزینه مشخص نشود، rpc.statd به‌طور پیش‌فرض از /var/lib/nfs استفاده می‌کند.

: پس از شروع، rpc.statd تلاش می‌کند UID و GID موثر خود را برابر با مالک و گروه زیردایرکتوری sm از این دایرکتوری تنظیم کند. پس از تغییر شناسه‌های موثر، rpc.statd تنها نیاز به دسترسی به فایل‌های موجود در sm و sm.bak در مسیر دایرکتوری وضعیت دارد.

-v, -V, --version: باعث می‌شود rpc.statd اطلاعات نسخه را در stderr نمایش داده و خارج شود.

فایل پیکربندی (CONFIGURATION FILE)

بسیاری از گزینه‌هایی که می‌توان در خط فرمان تنظیم کرد، از طریق مقادیر تعیین‌شده در بخش‌های [statd] یا در برخی موارد [lockd] از فایل پیکربندی /etc/nfs.conf نیز قابل کنترل هستند. مقادیر شناخته‌شده در بخش [statd] شامل port، outgoing-port، name، state-directory-path، و ha-callout هستند که هرکدام تأثیری مشابه با گزینه همنام خود دارند.

مقادیر شناخته‌شده در بخش [lockd] شامل port و udp-port هستند که به ترتیب تأثیری مشابه با گزینه‌های --nlm-port و --nlm-udp-port دارند.

امنیت (SECURITY)

دیمن rpc.statd باید به عنوان ریشه (کاربر ارشد) راه‌اندازی شود تا مجوزهای لازم برای ایجاد سوکت‌ها با پورت‌های مبدأ ممتاز و دسترسی به پایگاه‌داده اطلاعات وضعیت را به دست آورد. با این حال، از آنجا که rpc.statd یک سرویس شبکه‌ای طولانی‌مدت را اجرا می‌کند، به محض شروع به کار دسترسی‌های ریشه را رها می‌کند تا خطر حملات ارتقای سطح دسترسی را کاهش دهد.

در طول عملکرد عادی، شناسه کاربری موثری که انتخاب می‌کند مالک دایرکتوری وضعیت است. این امر به آن امکان می‌دهد تا پس از رها کردن امتیازات ریشه، همچنان به فایل‌های موجود در آن دایرکتوری دسترسی داشته باشد. برای کنترل اینکه rpc.statd کدام شناسه کاربری را انتخاب کند، کافی است با استفاده از chown(1) مالک دایرکتوری وضعیت را تعیین کنید.

شما همچنین می‌توانید با استفاده از کتابخانه tcp_wrapper یا iptables(8) از شنوندگان rpc.statd خود محافظت کنید. برای استفاده از کتابخانه tcp_wrapper، نام میزبان همتایانی را که مجاز به دسترسی هستند به /etc/hosts.allow اضافه کنید. از نام دیمن statd استفاده کنید حتی اگر باینری rpc.statd نام فایل متفاوتی داشته باشد.

برای اطلاعات بیشتر به صفحات راهنمای tcpd(8) و hosts_access(5) مراجعه کنید.

نکات تکمیلی (ADDITIONAL NOTES)

بازیابی قفل پس از راه‌اندازی مجدد برای حفظ یکپارچگی داده‌ها و جلوگیری از قفل شدن غیرضروری برنامه‌ها بسیار حیاتی است. برای کمک به rpc.statd در تطبیق درخواست‌های SM_NOTIFY با درخواست‌های NLM، مجموعه‌ای از بهترین شیوه‌ها باید رعایت شود، از جمله:

: نام نود UTS سیستم‌های شما باید با نام‌های DNS که همتایان NFS برای تماس با آن‌ها استفاده می‌کنند مطابقت داشته باشد
: نام نود UTS سیستم‌های شما همیشه باید نام‌های دامنه کاملاً واجد شرایط (FQDN) باشند
: نگاشت رفت و برگشت DNS (مستقیم و معکوس) نام نود UTS باید یکپارچه و سازگار باشد
: نام میزبانی که کلاینت برای سوار کردن (mount) سرور استفاده می‌کند باید با mon_name سرور در درخواست‌های SM_NOTIFY که ارسال می‌کند مطابقت داشته باشد

پیاده کردن (unmount) یک سیستم فایل NFS لزوماً مانع از پایش متقابل کلاینت یا سرور NFS نمی‌شود. هر دو ممکن است برای مدتی به پایش یکدیگر ادامه دهند در صورتی که ترافیک بعدی NFS میان آن دو منجر به اتصال‌های تازه و قفل‌گذاری فایل‌های اضافی شود.

در لینوکس، اگر ماژول کرنل lockd در طول عملکرد عادی تخلیه (unload) شود، تمام همتایان راه دور NFS از حالت پایش خارج می‌شوند. به عنوان مثال، این اتفاق در کلاینت NFS زمانی رخ می‌دهد که یک اتومونتر تمام نقاط اتصال NFS را به دلیل عدم فعالیت حذف کند.

فراخوانی‌های دسترسی‌پذیری بالا (High-availability callouts)

rpc.statd می‌تواند در طول پردازش درخواست‌های موفق SM_MON،‏ SM_UNMON و SM_UNMON_ALL، یا هنگام دریافت SM_NOTIFY، یک برنامه فراخوانی ویژه را اجرا کند. چنین برنامه‌ای ممکن است در محیط‌های NFS با دسترسی‌پذیری بالا (HA-NFS) برای ردیابی وضعیت قفل که ممکن است پس از راه‌اندازی مجدد سیستم نیاز به مهاجرت داشته باشد، استفاده شود.

نام برنامه فراخوانی با گزینه -H مشخص می‌شود. این برنامه با ۳ یا ۴ آرگومان اجرا می‌شود: اولین آرگومان بسته به دلیل فراخوانی، یکی از موارد add-client، del-client یا sm-notify است. دومین آرگومان، mon_name همتای تحت پایش است. سومین آرگومان، caller_name مدیر قفل درخواست‌کننده برای add-client یا del-client است، در غیر این صورت IP_address فراخوان‌کننده ارسال‌کننده SM_NOTIFY است. چهارمین آرگومان، state_value در درخواست SM_NOTIFY است.

پشتیبانی از IPv6 و TI-RPC

پروتکل TI-RPC پیش‌نیازی برای پشتیبانی از NFS روی IPv6 است. اگر پشتیبانی از TI-RPC در rpc.statd ساخته شده باشد، تلاش می‌کند شنوندگانی را روی پروتکل‌های انتقال شبکه که در /etc/netconfig به‌عنوان 'visible' علامت‌گذاری شده‌اند راه‌اندازی کند. تا زمانی که حداقل یک شنونده انتقال شبکه با موفقیت شروع شود، rpc.statd کار خواهد کرد.

متغیرهای محیطی (ENVIRONMENT)

RPC_STATD_NO_NOTIFY=: اگر روی یک عدد صحیح مثبت تنظیم شود، اثری مشابه --no-notify دارد.

فایل‌ها (FILES)

/var/lib/nfs/sm: دایرکتوری حاوی فهرست پایش
/var/lib/nfs/sm.bak: دایرکتوری حاوی فهرست اعلان
/var/lib/nfs/state: شماره وضعیت NSM برای این میزبان
/run/run.statd.pid: فایل شناسه فرآیند (pid)
/etc/netconfig: پایگاه‌داده قابلیت انتقال شبکه

همچنین ببینید (SEE ALSO)

sm-notify(8), nfs(5), rpc.nfsd(8), rpcbind(8), tcpd(8), hosts_access(5), iptables(8), netconfig(5)

RFC 1094 - "NFS: Network File System Protocol Specification"
RFC 1813 - "NFS Version 3 Protocol Specification"
OpenGroup Protocols for Interworking: XNFS, Version 3W - Chapter 11

نویسندگان (AUTHORS)

Jeff Uphoff <juphoff@users.sourceforge.net>
Olaf Kirch <okir@monad.swb.de>
H.J. Lu <hjl@gnu.org>
Lon Hohberger <hohberger@missioncriticallinux.com>
Paul Clements <paul.clements@steeleye.com>
Chuck Lever <chuck.lever@oracle.com>