• سیستم فایل NFS سرویس فایل شبکه

    همه می دانند که در سیستم های یونیکس، سیستم فایل به طور منطقی مجموعه ای از فایل سیستم های فیزیکی است که به یک نقطه متصل شده اند. یکی از اساسی ترین زیبایی های چنین سازمانی، به نظر من، توانایی تغییر پویا ساختار یک فایل سیستم موجود است. همچنین، به لطف تلاش های توسعه دهندگان، امروز ما این فرصت را داریم که تقریباً از هر نوع و به هر روشی مناسب، یک فایل سیستم را به هم متصل کنیم. صحبت از "روش"، من اول از همه می خواهم بر توانایی هسته سیستم عامل برای کار با سیستم های فایل از طریق اتصالات شبکه تاکید کنم.

    بسیاری از پروتکل های شبکه به ما توانایی کار با فایل های راه دور را می دهند، خواه FTP، SMB، Telnet یا SSH. به لطف توانایی کرنل، در نهایت، عدم وابستگی به نوع فایل سیستمی که در حال اتصال است، ما این قابلیت را داریم که با استفاده از برنامه mount، هر چیزی را و به هر شکلی متصل کنیم.

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

    آنچه برای این کار لازم است

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

    نصب و راه اندازی

    برای اجرای یک سرور NFS در اوبونتو 7.10 - Gutsy Gibbon، باید بسته های nfs-common و nfs-kernel-server را نصب کنم. اگر فقط به کلاینت NFS نیاز است، nfs-kernel-server نیازی به نصب ندارد.

    تنظیم سرور

    پس از اینکه همه بسته ها با موفقیت نصب شدند، باید بررسی کنید که آیا شبح NFS در حال اجرا است:

    /etc/init.d/nfs-kernel-server status

    اگر دیمون در حال اجرا نیست، باید با دستور شروع شود

    /etc/init.d/nfs-kernel-server start

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

    فایل اصلی پیکربندی سرور NFS در /etc/exports قرار دارد و دارای فرمت زیر است:

    فهرست ماشین 1 (گزینه 11، گزینه 12) ماشین 2 (گزینه 21، گزینه 22)

    فهرست راهنما — مسیر مطلقبه دایرکتوری سرور FS که می خواهید به آن دسترسی داشته باشید

    machineX- نام DNS یا آدرس IP رایانه مشتری که دسترسی از آن مجاز است

    گزینهXX- پارامترهای صادرات FS، رایج ترین آنها:

    • ro- دسترسی به فایل ها فقط برای خواندن مجاز است
    • rw- دسترسی برای خواندن / نوشتن داده شده است
    • no_root_squash- به‌طور پیش‌فرض، اگر به منبع NFS به‌عنوان روت وصل شوید، سرور به‌خاطر ایمنی، از طرف کاربر هیچ‌کس به فایل‌های سمت خود دسترسی خواهد داشت. با این حال، اگر این گزینه را فعال کنید، فایل های سمت سرور به صورت روت قابل دسترسی خواهند بود. مراقب این گزینه باشید.
    • no_subtree_check- به طور پیش فرض، اگر نه کل پارتیشن را روی سرور، بلکه فقط بخشی از سیستم فایل را صادر کنید، دیمون بررسی می کند که آیا فایل درخواستی به صورت فیزیکی در همان پارتیشن قرار دارد یا خیر. اگر کل پارتیشن را صادر می کنید یا نقطه اتصال FS صادر شده بر روی فایل های دیگر حجم های فیزیکی تأثیر نمی گذارد، می توانید این گزینه را فعال کنید. این باعث افزایش سرعت سرور می شود.
    • همگام سازی- در صورت وجود احتمال قطع ناگهانی یا قطع برق سرور، این گزینه را فعال کنید. اگر این گزینه فعال نباشد، خطر از دست رفتن داده ها هنگام توقف ناگهانی سرور NFS بسیار افزایش می یابد.

    بنابراین، فرض کنید می‌خواهیم به رایانه رومیزی ashep به فهرست /var/backups در رایانه لپ‌تاپ asep دسترسی دهیم. دسترسی به دایرکتوری برای کپی مورد نیاز است پشتیبان گیریفایل ها از asep-desktop. فایل من به این صورت است:

    /var/backups ashep-desktop(rw,no_subtree_check,sync)

    پس از افزودن یک خط به /etc/exports، باید سرور NFS را مجددا راه اندازی کنید تا تغییرات اعمال شوند.

    /etc/init.d/nfs-kernel-server راه اندازی مجدد

    همین. می توانید اتصال FS صادر شده را در رایانه مشتری شروع کنید.

    راه اندازی مشتری

    در سمت کلاینت، یک سیستم فایل راه دور به همان روشی که سایر سیستم ها نصب می شود - با دستور mount. همچنین، در صورت نیاز به اتصال خودکار فایل سیستم هنگام بوت شدن سیستم عامل، هیچ کس شما را از استفاده از /etc/fstab منع نمی کند. بنابراین، گزینه mount به صورت زیر خواهد بود:

    Mount -t nfs asep-laptop:/var/backups/ /mnt/ashep-laptop/backups/

    اگر همه چیز به خوبی پیش رفت و باید در هنگام بوت به طور خودکار به یک فایل سیستم از راه دور متصل شوید، فقط یک خط به /etc/fstab اضافه کنید:

    Ashep-laptop:/var/backups /mnt/ashep-laptop/backups nfs auto 0 0

    چه چیز دیگری

    بنابراین ما یک نمای کلی کاربردی و کوچک از امکانات NFS به دست آوردیم. البته این تنها بخش کوچکی از کاری است که NFS می تواند انجام دهد. این برای استفاده در خانه یا در یک دفتر کوچک کافی است. اگر این برای شما کافی نیست، توصیه می کنم ابتدا بخوانید

    پروتکل شبکه فایل سرور (NFS) یک استاندارد باز برای دسترسی کاربر از راه دور به سیستم های فایل است. بر اساس آن، فایل سیستم های متمرکز کارهای روزمره مانند پشتیبان گیرییا اسکن ویروس، و پارتیشن های دیسک به هم پیوسته نگهداری آسان تر از بسیاری از پارتیشن های کوچک و توزیع شده است.

    علاوه بر ارائه ذخیره سازی متمرکز، NFS ثابت کرده است که برای برنامه های کاربردی دیگر، از جمله کلاینت های بدون دیسک و نازک، خوشه بندی شبکه و میان افزارهای مشترک بسیار مفید است.

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

    از جایی که همه چیز شروع شد...

    پروتکل NFS توسط Sun Microsystems توسعه داده شد و در سال 1989 به عنوان RFC 1094 در اینترنت ظاهر شد. عنوان بعدی: مشخصات پروتکل سیستم فایل شبکه (NFS). جالب است بدانید که استراتژی Novell در آن زمان بهبود بیشتر خدمات فایل بود. تا همین اواخر، در حالی که جنبش منبع باز هنوز شتاب پیدا نکرده بود، Sun به دنبال افشای اسرار آن نبود. راه حل های شبکهبا این حال، حتی در آن زمان، شرکت اهمیت اطمینان از قابلیت همکاری با سایر سیستم ها را درک کرد.

    RFC 1094 شامل دو مشخصات اصلی بود. در زمان انتشار، Sun در حال توسعه نسخه سوم و بعدی مشخصات بود، که در RFC 1813 "مشخصات پروتکل NFS، نسخه 3" (مشخصات پروتکل نسخه 3 NFS) آمده است. نسخه 4 این پروتکلدر RFC 3010 NFS مشخصات پروتکل نسخه 4 (پروتکل NFS نسخه 4) تعریف شده است.

    NFS به طور گسترده در انواع هاست های یونیکس، شبکه های مایکروسافت و ناول و راه حل های IBM مانند AS400 و OS/390 استفاده می شود. ناشناخته در خارج از قلمرو شبکه، NFS مسلماً پرکاربردترین سیستم فایل شبکه مستقل از پلتفرم است.

    یونیکس ژنراتور بود

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

    NFS

    سیستم NFS برای استفاده در معماری سرویس گیرنده-سرور طراحی شده است. کلاینت به فایل سیستم صادر شده توسط سرور NFS از طریق یک نقطه اتصال روی کلاینت دسترسی پیدا می کند. چنین دسترسی معمولاً برای برنامه مشتری شفاف است.

    برخلاف بسیاری از سیستم های سرویس گیرنده/سرور، NFS از تماس های رویه از راه دور (RPC) برای تبادل اطلاعات استفاده می کند. به طور معمول، مشتری یک اتصال به یک پورت شناخته شده برقرار می کند و سپس، مطابق با پروتکل، درخواستی برای انجام یک عمل خاص ارسال می کند. در مورد فراخوانی رویه از راه دور، کلاینت یک فراخوانی رویه ایجاد می کند و سپس آن را برای اجرا به سرور ارسال می کند. توصیف همراه با جزئیات NFS در زیر ارائه خواهد شد.

    به عنوان مثال، فرض کنید یک کلاینت دایرکتوری usr2 را روی سیستم فایل ریشه محلی نصب کرده است:

    /root/usr2/ -> remote:/root/usr/

    اگر یک برنامه مشتری به منابع این دایرکتوری نیاز داشته باشد، به سادگی درخواستی را برای آن و نام فایل به سیستم عامل ارسال می کند که دسترسی از طریق سرویس گیرنده NFS را فراهم می کند. به عنوان مثال، دستور ساده یونیکس cd را در نظر بگیرید که "چیزی نمی داند". پروتکل های شبکه. تیم

    سی دی /root/usr2/

    دایرکتوری کار را روی سیستم فایل راه دور قرار می دهد بدون اینکه "حتی بداند" (کاربر نیز نیازی به دانستن آن ندارد) که سیستم فایل از راه دور است.

    با دریافت درخواست، سرور NFS بررسی می کند که آیا کاربر داده شده حق انجام عمل درخواستی را دارد یا خیر و در صورت مثبت بودن پاسخ، آن را انجام می دهد.

    بیایید بهتر بدانیم

    از دیدگاه مشتری، فرآیند نصب فایل سیستم راه دور به صورت محلی با استفاده از NFS شامل چندین مرحله است. همانطور که قبلا ذکر شد، کلاینت NFS یک فراخوان رویه راه دور برای اجرای آن در سرور ارسال می کند. توجه داشته باشید که در یونیکس مشتری یک برنامه واحد است (فرمان mount)، در حالی که سرور در واقع به صورت چند برنامه با موارد زیر پیاده سازی می شود. حداقل مجموعه: سرویس نقشه برداری پورت (نقشه نگار پورت)، mount daemon (mount daemon) و سرور NFS.

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

    (این مطالب بر روی نسخه سوم NFS متمرکز شده است، زیرا در حال حاضر رایج ترین نسخه است. نسخه چهارم هنوز توسط اکثر پیاده سازی ها پشتیبانی نمی شود.)

    سرویس ترجمه پورت سرور طبق پروتکل پشتیبانی شده و پورتی که mount daemon روی آن اجرا می شود به درخواست ها پاسخ می دهد. برنامه mount کلاینت ابتدا با mount daemon سرور ارتباط برقرار می کند و سپس دستور mount را از طریق RPC برای آن ارسال می کند. اگر این رویهبا موفقیت، برنامه مشتری به سرور NFS (پورت 2049) متصل می شود و با استفاده از یکی از 20 رویه راه دور تعریف شده در RFC 1813 و فهرست شده در جدول 1، به سیستم فایل راه دور دسترسی پیدا می کند.

    معنای بیشتر دستورات بصری است و هیچ مشکلی برای مدیران سیستم ایجاد نمی کند. فهرست زیر که با استفاده از tcdump تولید شده است، دستور خواندن را که توسط دستور یونیکس cat برای خواندن فایلی به نام test-file استفاده می‌شود، نشان می‌دهد:

    10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 مراجعه fh 32.0/ 224145 "test-file" 10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 جستجو fh 32.0/ 224145 "test-file" 10:30:16.012729 eth0 192.168.1.254.34702000 192.168.1.254.3476: 2 4307 (DF) 10:30:16.012729 eth0 192.168.1.254.3476097947: پاسخ خوب 3492875163 > 192.168.1.252.2049: 140 خوانده شده fh 32.0/ 224307 4096 بایت @ 0 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 خوانده شده fh 32.0/ 224307 4096 بایت @ 0 10:30:16.013650 eth0 192.168.1.1.2801 دوباره خوانده شده 10: 30:16.013650 eth0 192.168.1.254.3492875163: پاسخ خوب 108 خوانده شده (DF)

    NFS به طور سنتی بر روی UDP پیاده سازی شده است. با این حال، برخی از نسخه های NFS از TCP پشتیبانی می کنند (پشتیبانی TCP در مشخصات پروتکل تعریف شده است). مزیت اصلی TCP مکانیزم ارسال مجدد کارآمدتر در شبکه های غیر قابل اعتماد است. (در مورد UDP، اگر خطایی رخ دهد، پس پیام کاملیک RPC متشکل از چندین بسته UDP دوباره ارسال می شود. اگر TCP وجود داشته باشد، فقط قطعه خراب دوباره ارسال می شود.)

    دسترسی به NFS

    پیاده‌سازی‌های NFS معمولاً از چهار روش اعطای دسترسی پشتیبانی می‌کنند: از طریق ویژگی‌های کاربر/فایل، در سطح اشتراک، در سطح گره اصلی، و به عنوان ترکیبی از روش‌های دسترسی دیگر.

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

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

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

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

    سبک پنگوئن NFS

    مطالب مرتبط با لینوکس ارائه شده در اینجا بر اساس سیستم Red Hat 6.2 با هسته نسخه 2.4.9 است که با نسخه 0.1.6 بسته nfs-utils عرضه می شود. نسخه های جدیدتر نیز وجود دارد: در زمان نگارش این مقاله، آخرین به روز رسانی بسته nfs-utils 0.3.1 است. قابل دانلود در: .

    بسته nfs-utils شامل موارد زیر است فایل های اجرایی: exportfs، lockd، mountd، nfsd، nfsstat، nhfsstone، rquotad، showmount و statd.

    متأسفانه، پشتیبانی NFS گاهی اوقات برای مدیران لینوکس گیج کننده است، زیرا در دسترس بودن یک ویژگی خاص به طور مستقیم به شماره نسخه هسته و بسته nfs-utils بستگی دارد. خوشبختانه، اکنون اوضاع در این زمینه در حال بهبود است: جدیدترین کیت های توزیع شامل آخرین نسخه های هر دو است. برای نسخه های قبلی، بخش 2.4 NFS-HOWTO لیست کاملی از عملکردهای سیستم موجود برای هر ترکیبی از هسته و بسته nfs-utils را ارائه می دهد. توسعه دهندگان سازگاری بسته با نسخه های قبلی را حفظ می کنند و توجه زیادی به امنیت و رفع اشکالات نرم افزاری دارند.

    پشتیبانی NFS باید در زمان کامپایل هسته آغاز شود. در صورت لزوم، قابلیت کار با NFS نسخه 3 نیز باید به هسته اضافه شود.

    برای توزیع هایی که از linuxconf پشتیبانی می کنند، پیکربندی سرویس های NFS هم برای کلاینت ها و هم برای سرورها آسان است. با این حال، راه‌اندازی سریع NFS با استفاده از linuxconf اطلاعاتی در مورد فایل‌هایی که ایجاد یا ویرایش شده‌اند را ارائه نمی‌دهد، که در صورت خرابی سیستم برای مدیر بسیار مهم است. معماری NFS در لینوکس به طور ضعیفی با نسخه BSD همراه است، بنابراین فایل‌ها و برنامه‌های پشتیبانی لازم برای مدیرانی که BSD، Sun OS 2.5 یا نسخه‌های قبلی NFS را اجرا می‌کنند، به راحتی پیدا می‌شوند.

    فایل /etc/exports، مانند نسخه های قبلی BSD، سیستم های فایلی را مشخص می کند که کلاینت های NFS مجاز به دسترسی هستند. علاوه بر این، دارای تعدادی ویژگی اضافی مربوط به مدیریت و مسائل امنیتی است که ابزاری برای تنظیم دقیق در اختیار مدیر قرار می دهد. این یک فایل متنی متشکل از ورودی ها، خطوط خالی یا خطوط نظر است (نظرات با # شروع می شوند).

    فرض کنید می خواهیم به کلاینت ها دسترسی فقط خواندنی به دایرکتوری home/در میزبان Lefty بدهیم. این با ورودی زیر در /etc/exports مطابقت دارد:

    /home (ro)

    در اینجا باید به سیستم بگوییم که کدام دایرکتوری ها را با استفاده از mount daemon rpc.mountd در دسترس قرار می دهیم:

    # exportfs -r exportfs: هیچ نام میزبان در /home (ro) مشخص نشده است، برای جلوگیری از هشدار #*(ro) را تایپ کنید.

    هنگام اجرا، دستور exportfs هشدار می‌دهد که /etc/exports دسترسی به یک گره خاص را محدود نمی‌کند و یک ورودی متناظر در /var/lib/nfs/etab از /etc/exports ایجاد می‌کند که به شما می‌گوید کدام منابع را می‌توان با cat مشاهده کرد:

    # cat /var/lib/nfs/etab /home (ro,async,wdelay,hide,secure,root_squash, no_all_squash,subtree_check, safe_locks, mapping=identity,anonuid= -2,anongid=-2)

    سایر گزینه های فهرست شده در etab شامل پیش فرض های استفاده شده توسط NFS می شود. جزئیات در زیر توضیح داده خواهد شد. برای اعطای دسترسی به فهرست /home، خدمات NFS مناسب باید راه اندازی شود:

    # portmap # rpc.mountd # rpc.nfsd # rpc.statd # rpc.rquotad

    در هر زمانی پس از شروع mount daemon (rpc.mountd)، می توانید با مشاهده محتویات فایل /proc/fs/nfs/exports، در مورد فایل های جداگانه موجود برای خروجی پرس و جو کنید:

    # cat /proc/fs/nfs/exports # نسخه 1.0 # Path Client(Flags) # IPs /home 192.168.1.252 (ro,root_squash,async, wdelay) # 192.168.1.252 #

    همین مورد را می توان با استفاده از دستور showmount با گزینه -e مشاهده کرد:

    # showmount -e لیست صادرات برای چپ: /home (همه) #

    کمی جلوتر، دستور showmount را می‌توان برای تعیین تمام فایل‌سیستم‌های نصب‌شده یا به عبارت دیگر، برای یافتن اینکه کدام میزبان‌ها برای سیستمی که فرمان showmount را اجرا می‌کند، کلاینت‌های NFS هستند، استفاده کرد. دستور showmount -a تمام نقاط نصب مشتری را فهرست می کند:

    # showmount -a همه نقاط نصب در سمت چپ: 192.168.1.252:/home #

    همانطور که در بالا ذکر شد، اکثر پیاده سازی های NFS از نسخه های مختلف این پروتکل پشتیبانی می کنند. پیاده سازی لینوکس به شما امکان می دهد لیست نسخه های NFS را که با تعیین گزینه -N برای mount daemon اجرا می شوند، محدود کنید. به عنوان مثال، برای شروع NFS نسخه 3 و فقط نسخه 3، دستور زیر را وارد کنید:

    # rpc.mountd -N 1 -N 2

    کاربران انتخابیممکن است ناخوشایند به نظر برسد که شبح NFS (rpc.nfsd) در لینوکس منتظر بسته های نسخه 1 و نسخه 2 باشد، اگرچه این کار به اثر مطلوب عدم پشتیبانی از پروتکل مربوطه می رسد. امیدواریم توسعه دهندگان نسخه های بعدی اصلاحات لازم را انجام دهند و بتوانند به هماهنگی بیشتری بین اجزای بسته در رابطه با نسخه های مختلف پروتکل دست یابند.

    "شنا با پنگوئن"

    دسترسی به Lefty پیکربندی شده بالا، سیستم فایل NFS صادر شده روشن است مبتنی بر لینوکس، بستگی به سیستم عامل مشتری دارد. سبک نصب برای اکثر سیستم عامل های خانواده یونیکس مانند سیستم عامل اصلی Sun و سیستم های BSD یا سولاریس جدیدتر است. از آنجایی که این مقاله بر روی لینوکس و سولاریس تمرکز دارد، بیایید به پیکربندی مشتری Solaris 2.6 از نقطه نظر برقراری ارتباط با نسخه لینوکس NFS که در بالا توضیح دادیم نگاه کنیم.

    با ویژگی هایی که از Solaris 2.6 به ارث رسیده است، پیکربندی آن برای عمل به عنوان یک سرویس گیرنده NFS آسان است. این فقط به یک دستور نیاز دارد:

    # mount -F nfs 192.168.1.254:/home /tmp/tmp2

    فرض کنید دستور mount قبلی موفقیت آمیز بوده است، سپس دستور mount بدون گزینه خروجی زیر را خواهد داشت:

    # mount / در /dev/dsk/c0t0d0s0 read/write/setuid/ largefiles در دوشنبه 3 سپتامبر 10:17:56 2001 ... ... /tmp/tmp2 در 192.168.1.254:/home read/ write/remote در دوشنبه 3 سپتامبر 23 23:20

    اجازه دهید خروجی tcpdump را در هاست Lefty پس از اینکه کاربر دستور ls /tmp/tmp2 را در میزبان Sunny وارد کرد، تجزیه و تحلیل کنیم:

    # tcpdump host lefty و host sunny -s512 06:07:43.490583 sunny.2191983953 > lefty.mcwrite.n.nfs: 128 getattr fh ناشناخته/1 (DF) 06:07:43.43.4906write >sunny.490678 : پاسخ خوب 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:07:43.491397 sunny.2191983954 > lefty.mcwrite.n.nfs: 132D30001: 132000: 132/01:1300:132:1300:132:130:130. 63 lefty.mcwrite.n. nfs > sunny.2191983954: پاسخ ok 120 دسترسی به c0001 (DF) 06:07:43.492296 sunny.2191983955 > lefty.mcwrite.n.2140001.nfs. tes @ 0x000000000 (DF) 0 06:07:43.492417 lefty.mcwrite.n.nfs > sunny.2191983955: پاسخ ok 1000 readdirplus (DF)

    می بینیم که گره Sunny یک توصیفگر فایل (fh) برای ls می خواهد که گره Lefty در پاسخ به آن OK می فرستد و ساختار دایرکتوری را برمی گرداند. سپس Sunny مجوز محتویات دایرکتوری را بررسی می کند (132 دسترسی fh) و یک پاسخ مجوز از Lefty دریافت می کند. سپس گره Sunny محتویات کامل دایرکتوری را با استفاده از رویه readdirplus می خواند. فراخوانی روش از راه دور در RFC 1813 توضیح داده شده است و در ابتدای این مقاله ذکر شده است.

    اگرچه توالی دستورات برای دسترسی به سیستم های فایل از راه دور بسیار ساده است، تعدادی از شرایط می تواند باعث شود سیستم به درستی نصب شود. قبل از نصب دایرکتوری، نقطه اتصال باید از قبل وجود داشته باشد، در غیر این صورت باید با استفاده از دستور mkdir ایجاد شود. معمولاً تنها دلیل خطاها در سمت کلاینت فقدان دایرکتوری mount محلی است. با این حال، بسیاری از مشکلات مرتبط با NFS به دلیل عدم تطابق بین مشتری و سرور یا پیکربندی نادرست سرور است.

    ساده ترین راه برای عیب یابی مشکلات سرور، از طریق میزبانی است که سرور در آن در حال اجرا است. با این حال، زمانی که شخص دیگری به جای شما سرور را مدیریت می کند، این همیشه امکان پذیر نیست. یک راه سریع برای اطمینان از اینکه سرویس های سرور مناسب به درستی پیکربندی شده اند، استفاده از دستور rpcinfo با گزینه -p است. از میزبان Solaris Sunny، می توانید تعیین کنید که کدام فرآیندهای RPC در میزبان لینوکس ثبت شده است:

    # rpcinfo -p 192.168.1.254 برنامه نسخه پروتو پورت سرویس 100000 2 tcp 111 rpcbind 100000 2 udp 111 rpcbind 100024 1 udp 692 وضعیت 100024 692 100024 100024 100024 100000 untd /100005 3 tcp 1024 mountd 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100021 1 udp 1026 nlockmgr 100021 100021 100021 100021 100021 26 nlockmgr#

    توجه داشته باشید که اطلاعات نسخه نیز در اینجا ارائه شده است که در مواقعی که سیستم نیاز به پشتیبانی از پروتکل های مختلف NFS داشته باشد بسیار مفید است. اگر هر سرویسی روی سرور اجرا نمی شود، این وضعیت باید اصلاح شود. اگر mount ناموفق باشد، دستور rpcinfo -p زیر به شما می‌گوید که سرویس mountd روی سرور از کار افتاده است:

    # rpcinfo -p 192.168.1.254 برنامه نسخه پروتو پورت سرویس 100000 2 tcp 111 rpcbind ... ... 100021 4 udp 1026 nlockmgr #

    دستور rpcinfo برای اطلاع از فعال بودن یک فرآیند از راه دور خاص بسیار مفید است. گزینه -p مهمترین سوئیچ است. برای مشاهده تمامی ویژگی های rpcinfo به صفحه مرد مراجعه کنید.

    ابزار مفید دیگر دستور nfsstat است. با کمک آن می توانید متوجه شوید که آیا کلاینت ها واقعاً به سیستم فایل صادر شده دسترسی دارند یا خیر و همچنین اطلاعات آماری را مطابق نسخه پروتکل نمایش دهید.

    در نهایت، یکی دیگر از ابزارهای نسبتا مفید برای تعیین علل خرابی سیستم، tcpdump است:

    # tcpdump host lefty و host sunny -s512 tcpdump: گوش دادن در eth0 06:29:51.773646 sunny.2191984020 > lefty.mcwrite.n.nfs: 140 جستجو fh Unknown/1"test.c":79:51.773646 آفتابی s > sunny .2191984020: پاسخ خوب 116 خطای جستجو: چنین فایل یا دایرکتوری وجود ندارد (DF) 06:29:51.774593 sunny.2191984021 > lefty.mcwrite.n.nfs: 128 getattr:4.71cwrite: 128 getattr:fh ite.n.nfs > sunny.2 191984021: پاسخ خوب 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:29:51.775289 sunny.2192 > leftyn40m "test.c" (DF) 06:29:51 0.775357 lefty.mcwrite.n.nfs > sunny.2191984022: پاسخ خوب 116 جستجو خطا: چنین فایل یا دایرکتوری وجود ندارد (DF) 06:29:51.776019:wwrite.nfs.4. 84 ایجاد fh ناشناس/1 "test.c" (DF) 06:29:5 1.776169 lefty.mcwrite.n.nfs > sunny.2191984023: پاسخ ok 120 ایجاد خطا: مجوز رد شد (DF)

    لیست فوق پس از اجرا به دست آمد دستورالعمل های لمسی test.c، دنباله اقدامات زیر را منعکس می کند: ابتدا دستور لمسی سعی می کند به فایلی با نام test.c دسترسی پیدا کند، سپس به دنبال دایرکتوری با همین نام می گردد و پس از تلاش های ناموفق، سعی می کند فایل test.c را ایجاد کند که این نیز به موفقیت منجر نمی شود.

    اگر سیستم فایل نصب شده باشد، بیشتر اشتباهات رایجمرتبط با مجوزهای معمولی یونیکس. استفاده Sun از uid یا NIS+ از تنظیم مجوزها به صورت سراسری در همه سیستم‌های فایل جلوگیری می‌کند. برخی از مدیران دایرکتوری های "باز" ​​را تمرین می کنند، جایی که مجوز خواندن آنها به "کل جهان" داده می شود. با این حال، به دلایل امنیتی باید از این کار اجتناب شود. از نگرانی‌های امنیتی که بگذریم، این هنوز یک روش بد است، زیرا کاربران به ندرت داده‌هایی را با هدف خواندن آن‌ها توسط همه ایجاد می‌کنند.

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

    سرور NFS، نسخه سولاریس

    پیکربندی Solaris برای عمل به عنوان یک سرور NFS به آسانی لینوکس است. با این حال، دستورات و مکان فایل ها تا حدودی متفاوت است. در بوت استرپسولاریس، پس از رسیدن به سطح بوت 3 (سطح اجرا 3)، خدمات NFS به طور خودکار شروع می شود و همه سیستم های فایل صادر می شوند. برای شروع دستی این فرآیندها، دستور را وارد کنید:

    #/usr/lib/nfs/mountd

    برای شروع mount daemon و سرور NFS، تایپ کنید:

    #/usr/lib/nfs/nfsd

    با شروع نسخه 2.6، Solaris دیگر از فایل صادراتی برای تعیین اینکه کدام سیستم فایل را صادر کند، استفاده نمی کند. اکنون فایل ها با استفاده از دستور share صادر می شوند. فرض کنید می خواهیم به هاست های راه دور اجازه مونت /export/home را بدهیم. برای این کار دستور زیر را وارد کنید:

    -F nfs /export/home را به اشتراک بگذارید

    تمهیدات امنیتی

    امنیت در لینوکس

    برخی از سرویس‌های سیستم NFS مبتنی بر لینوکس مکانیسم اضافی برای محدود کردن دسترسی از طریق لیست‌ها یا جداول کنترل دارند. در سطح داخلی، این مکانیسم با استفاده از کتابخانه tcp_wrapper، که از دو فایل برای تشکیل لیست های کنترل دسترسی استفاده می کند، پیاده سازی می شود: /etc/hosts.allow و /etc/hosts/deny. مروری جامع بر قوانین کار با tcp_wrapper خارج از محدوده این مقاله است، اما اصل اساسی به شرح زیر است: تطبیق ابتدا با etc/hosts.allow و سپس با /etc/hosts انجام می شود. انکار. اگر قانون پیدا نشد، سرویس سیستم درخواستی ارائه نمی شود. برای دور زدن آخرین نیاز و ارائه یک سطح امنیتی بسیار بالا، می توانید ورودی زیر را به انتهای /etc/hosts.deny اضافه کنید:

    ALL: همه

    پس از آن می توان از /etc/hosts.allow برای تنظیم این یا آن حالت عملیات استفاده کرد. به عنوان مثال، فایل /etc/hosts. اجازه، که هنگام نوشتن این مقاله از آن استفاده کردم، حاوی خطوط زیر بود:

    lockd:192.168.1.0/255.255.255.0 mountd:192.168.1.0/255.255.255.0 portmap:192.168.1.0/255.255.255.0 rquotad:192.168.1.0.192.168.1.0/255.255.255.0 rquotad:192.168.1.1.0. 2 .168.1.0/255.255.255.0

    این اجازه می دهد تا نوعی دسترسی به گره ها قبل از اعطای دسترسی در سطح برنامه. در لینوکس، دسترسی در سطح برنامه توسط فایل /etc/exports کنترل می شود. این شامل مدخل هایی در قالب زیر است:

    صادرات دایرکتوری (فضا) میزبان|شبکه(گزینه ها)

    دایرکتوری صادر شده دایرکتوری است که شبح nfsd مجاز به پردازش درخواستی است. «Host|Network» میزبان یا شبکه‌ای است که به سیستم فایل صادر شده دسترسی دارد و «گزینه‌ها» تعیین می‌کنند که آیا شبح nfsd دسترسی فقط خواندنی یا نقشه‌برداری شناسه کاربر را بر استفاده از منبع مشترک تحمیل می‌کند یا خیر.

    مثال زیر به کل دامنه mcwrite.net دسترسی فقط خواندنی به /home/mcwrite.net می دهد:

    /home/mcwrite.net *.mcwrite.net(ro)

    نمونه‌های بیشتر را می‌توانید در صفحه مرد صادرات پیدا کنید.

    امنیت NFS در سولاریس

    در سولاریس، امکان ارائه دسترسی NFS مشابه لینوکس است، اما در این حالت، محدودیت‌هایی با استفاده از گزینه‌های خاصی در دستور اشتراک‌گذاری با سوئیچ -o تنظیم می‌شود. مثال زیر نحوه فعال کردن نصب فقط خواندنی /export/mcwrite.net را در هر میزبانی در دامنه mcwrite.net نشان می‌دهد:

    #share -F nfs -o ro=.mcwrite.net/ export/ mcwrite.net

    صفحه مرد share_nfs نحوه اعطای دسترسی با استفاده از لیست های کنترل در Solaris را شرح می دهد.

    منابع اینترنتی

    NFS و RPC بدون «سوراخ» نبودند. به طور کلی، NFS نباید در اینترنت استفاده شود. با اجازه دادن به هر نوع دسترسی از طریق NFS نمی توانید فایروال ها را سوراخ کنید. همه وصله‌های RPC و NFS باید به دقت نظارت شوند و منابع متعدد اطلاعات امنیتی می‌توانند به شما کمک کنند. دو منبع محبوب Bugtraq و CERT هستند:

    اولین مورد را می توان به طور منظم در جستجوی اطلاعات لازم مشاهده کرد یا از اشتراک در یک خبرنامه دوره ای استفاده کرد. مورد دوم، شاید در مقایسه با دیگران، اطلاعات نه چندان سریع را ارائه می دهد، اما در حجم نسبتاً کامل و بدون نشانه ای از شور و شوق، مشخصه برخی از سایت های اختصاص داده شده به امنیت اطلاعات است.

    خدمات شبکه

    سخنرانی 10

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

    هنگام شبکه، دسترسی از طریق شبکه به سیستم فایل، مکان قابل توجهی را اشغال می کند. در این حالت قسمت های کلاینت و سرور به همراه فایل سیستم شبکه تشکیل می شوند سرویس فایل

    یکی از اجزای کلیدی یک سیستم عامل توزیع شده، سیستم فایل شبکه است. سیستم فایل شبکه توسط یک یا چند کامپیوتر که فایل ها را ذخیره می کنند پشتیبانی می شود (سرورهای فایل)

    مشتریکامپیوترها این فایل سیستم ها را به سیستم فایل محلی خود متصل یا نصب می کنند

    سرویس فایلشامل برنامه های سرور و برنامه های سرویس گیرنده است که از طریق یک شبکه با استفاده از یک پروتکل ارتباط برقرار می کنند.

    خدمات فایل شامل خود سرویس فایل (عملیات فایل) و سرویس دایرکتوری (مدیریت دایرکتوری) است.

    مدل سرویس فایل شبکه شامل عناصر زیر است:

    سیستم فایل محلی (FAT، NTFS)

    رابط سیستم فایل محلی (تماس های سیستمی)

    سرور سیستم فایل شبکه

    سرویس گیرنده سیستم فایل شبکه ( ویندوز اکسپلوررپوسته یونیکس و غیره)

    رابط سیستم فایل شبکه (تکرار تماس های سیستم فایل سیستم محلی)

    پروتکل کلاینت-سرور سیستم فایل شبکه (بلاک پیام سرور SMB برای ویندوز، NFS (سیستم فایل شبکه) و FTP (پروتکل انتقال فایل) برای یونیکس)

    رابط سیستم فایل شبکه

    انواع مختلفی از اینترفیس ها وجود دارد که با موارد زیر مشخص می شوند:

    ساختار فایل. اکثر سیستم های فایل شبکه از فایل های مسطح پشتیبانی می کنند

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

    معناشناسی جداسازی فایل:

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

    معناشناسی جلسهتغییرات پس از باز شدن فایل شروع می شود و پس از بسته شدن فایل به پایان می رسد. به عبارت دیگر، برای سایر فرآیندها، تغییرات تنها پس از بسته شدن فایل قابل مشاهده است. که در این موردمشکلی در اشتراک گذاری فایل وجود دارد. معناشناسی فایل های تغییرناپذیرفایل فقط قابل ایجاد و خواندن است. همچنین می توانید فایل را با نام دیگری دوباره ایجاد کنید. بنابراین، فایل را نمی توان تغییر داد، اما می توان آن را با یک فایل جدید جایگزین کرد. مشکل اشتراک گذاری وجود ندارد.



    مکانیسم معاملهاین روشی برای کار با فایل های مشترک با استفاده از مکانیسم تراکنش (عملیات تقسیم ناپذیر) است.

    کنترل دسترسی. به عنوان مثال، برای ویندوز NT/2000 دو مکانیسم وجود دارد: در سطح دایرکتوری (برای FAT) و در سطح فایل (NTFS).

    واحد دسترسیمدل آپلود/دانلود کل فایل (FTP). مدل دوم استفاده از عملیات روی فایل ها است.

    1.4 سیستم فایل شبکه

    سیستم فایل CIFS بر بازار سیستم فایل شبکه برای پلتفرم ویندوز تسلط دارد. در پلتفرم یونیکس، سیستم فایل اصلی، سیستم فایل شبکه (NFS) است. علاوه بر این، NFS اولین سیستم فایل به طور گسترده پذیرفته شده در نظر گرفته می شود که در اواسط دهه 1980 اتفاق افتاد. با این حال، با وجود برخی از عملکردهای مشترک CIFS و NFS (اینها سیستم های فایل شبکه هستند که به مشتریان اجازه دسترسی به منابع سرور را می دهند)، این سیستم ها ویژگی های معماری کاملاً متفاوتی دارند. با انتشار NFS نسخه 4، برخی از تفاوت ها تجدید نظر شده است.
    پروتکل CIFS داده های خدمات مربوط به هر مشتری را ذخیره می کند. قبل از نسخه 3، NFS وضعیت مشتری را حفظ نمی کرد، که در نسخه 4 تغییر کرد.
    مشتری NFS با سرور NFS برای ایجاد یک جلسه "مذاکره" نمی کند. اقدامات امنیتی برای کل جلسه یا هر عملیات ارتباطی بین مشتری و سرور انجام می شود. اجرای گزینه دوم بسیار گران است، بنابراین NFS وظیفه امنیتی را به مشتری واگذار می کند. سرور «فرض می‌کند» که شناسه‌های کاربر در سیستم‌های کلاینت و سرور یکسان هستند (و مشتری قبل از اینکه به آنها اجازه ورود با شناسه مشخص شده را بدهد، هویت کاربر را تأیید کرده است). علاوه بر این، NFS با کنترل سیستم های فایلی که مشتری می تواند نصب کند، سطح خاصی از امنیت را فراهم می کند. هر بار که یک کلاینت CIFS فایلی را باز می‌کند، یک توصیفگر فایل (یعنی داده‌های سرویسی که سرور باید ذخیره کند) را به دست می‌آورد و از آن برای انجام خواندن یا نوشتن در سمت کلاینت استفاده می‌کند، سرور NFS از سرور درخواست می‌کند که توصیف‌گر فایل را برمی‌گرداند. این توصیفگر فایل توسط کلاینت هایی پردازش می شود که از استانداردهای NFS 3 و NFS 2 پشتیبانی می کنند. سرویس گیرنده توصیفگر فایل دریافتی را در حافظه پنهان ذخیره می کند و انتظار دارد که توصیفگر همیشه به همان فایل اشاره کند.
    برای کسانی که با یونیکس آشنا هستند، یک توصیفگر فایل معمولاً از یک شماره ایند، یک تعداد تولید inode و یک شناسه فایل که با پارتیشن دیسک مرتبط است تشکیل شده است. کافی است بگوییم که inode یک ساختار داده بسیار مهم است که در سیستم های فایل یونیکس استفاده می شود. برای حذف توصیفگرهای کش شده توسط کلاینت ها، اطلاعات کافی ذخیره می شود که در صورت تغییر فایل مربوط به توصیفگر ضروری است و توصیفگر باید به فایل دیگری اشاره کند. به عنوان مثال، اگر فایلی حذف شود و فایلی به همین نام به جای آن کپی شود، شمارنده تولید inode تغییر می کند و توصیفگر فایل ذخیره شده توسط مشتری باطل می شود. سیستم فایل NFS 4 دارای تفاوت های پیاده سازی است.
    برخی از کلاینت‌های NFS با ذخیره‌سازی داده‌ها روی دیسک‌ها، حافظه پنهان سمت سرویس گیرنده را انجام می‌دهند که شبیه به ذخیره‌سازی CIFS است. همچنین، برخی از سرویس گیرندگان NFS، مقدار وقفه ها را بسته به زمان پاسخگویی سرور تغییر می دهند. هر چه سرور کندتر پاسخ می دهد، مقدار زمان وقفه بیشتر می شود و بالعکس.
    سیستم فایل NFS به گونه ای طراحی شده بود که مستقل از حمل و نقل باشد و در اصل از پروتکل انتقال UDP استفاده می کرد. انواع مختلف NFS ممکن است از TCP و پروتکل های دیگر استفاده کنند.

    1.4.1 سیستم فایل شبکه نسخه 3

    سیستم فایل NFS 3 امکان عملکرد سریعتر را به خصوص برای فایل های حجیم، به کلاینت و سرور اجازه می دهد تا به صورت پویا حداکثر مقدار داده ای را که در یک عنصر منطقی بسته منتقل می شود هنگام نوشتن یا خواندن انتخاب کنند. در سیستم فایل NFS 2، محدودیت اندازه بسته 8 کیلوبایت اعمال شد. به عبارت دیگر، مشتری می تواند حداکثر 8 کیلوبایت در یک درخواست نوشتن ارسال کند و سرور می تواند حداکثر 8 کیلوبایت را در یک پاسخ خواندن ارسال کند. علاوه بر این، NFS 3 تعدیل فایل ها و اندازه داده ها را دوباره تعریف کرد. اینها اکنون مقادیر 64 بیتی هستند، به جای 32 بیتی در NFS 2.
    در زیر برخی از ویژگی های NFS 3 آورده شده است.
    ■ توصیفگرهای فایل NFS 3 از نظر اندازه متغیر هستند. حداکثر اندازه آنها 64 بیت است.
    ■ سیستم فایل NFS 3 به مشتریان و سرورها امکان انتخاب می دهد حداکثر اندازهنام فایل ها و دایرکتوری ها
    ■ NFS 3 لیستی از خطاهایی را تعریف می کند که سرور می تواند به کلاینت ها بازگرداند. سرور باید یکی از خطاهای تعریف شده را برگرداند یا اصلا خطایی نداشته باشد.
    ■ در NFS 3، سرور مجاز است داده هایی را که کلاینت به همراه درخواست نوشتن ارسال می کند، کش کند. سرور می تواند داده ها را کش کند و قبل از اینکه داده ها روی دیسک نوشته شوند، پاسخی به درخواست مشتری ارسال کند. یک دستور COMMIT نیز اضافه شده است تا به مشتری اجازه می دهد تا تأیید کند که تمام داده های ارسال شده روی دیسک نوشته شده اند. این امکان ایجاد تعادل بین بهبود عملکرد و حفظ یکپارچگی داده ها را فراهم می کند.
    ■ NFS 3 تعداد عملیات درخواست/پاسخ بین کلاینت و سرور را کاهش داده است. برای این کار داده های ویژگی فایل به همراه درخواست اولیه ارسال می شود. در NFS 2، کلاینت باید نام فایل ها و دسته های مربوط به هر فایل را به دست می آورد، تنها پس از آن ویژگی های فایل منتقل می شد.

    1.4.2 شبکه فایل سیستم نسخه 4

    NFS 4 اصول اولیه را کاملاً بازنگری کرد و بسیاری از ویژگی‌های خاص CIFS را پیاده‌سازی کرد که باعث ناراحتی بسیاری از عذرخواهی‌کنندگان NFS شد. اگر به تاریخچه سیستم های فایل شبکه نگاه کنید، می بینید که NFS گسترده شده است. سیستم فایل SMB با در نظر گرفتن نقاط قوت و ضعف NFS طراحی شده است و اکنون حداقل در محیط کلاینت CIFS/SMB رایج تر است و NFS با در نظر گرفتن تمام مزایا و معایب CIFS/SMB در حال تکامل است. در زیر ویژگی هایی وجود دارد که برای بهبود عملکرد و امنیت و بهبود قابلیت همکاری با CIFS به NFS 4 اضافه شده است.
    ■ NFS 4 پرس و جوی COMPOUND را معرفی کرد که به شما امکان می دهد چندین پرس و جو را در یک پرس و جو و چندین پاسخ را در یک پاسخ واحد قرار دهید. این نوآوری برای بهبود عملکرد با کاهش بار شبکه و کاهش تأخیر هنگام ارسال درخواست ها و پاسخ ها در سراسر شبکه در نظر گرفته شده است. اگر این تا حدودی یادآور ویژگی CIFS AndX SMB باشد (به بخش 3.3.5.1 مراجعه کنید)، ممکن است یک تصادف عادی نباشد.
    ■ سیستم فایل شبکه نسخه 4 برخی از ویژگی ها را از WebNFS Sun به عاریت گرفته است. به طور خاص، در NFS 4، برخی از پروتکل های ثانویه در مشخصات پایه پشتیبانی می شوند، که NFS را برای استفاده با فایروال ها مناسب تر می کند. NFS 3 و قبل از آن از یک پروتکل ویژه برای نصب یک اشتراک سرور در درخت سیستم فایل محلی استفاده می کرد. از آنجایی که سرویس پروتکل mount اختصاص داده نشده است پورت TCPیا UDP، کلاینت ابتدا درخواستی را به شبح portmapper ارسال می کند، که شماره پورتی را که سرویس mount درخواست ها را در آن گوش می دهد، ارائه می دهد. بنابراین، علاوه بر NFS، پروتکل‌های نقشه‌برداری mount و port نیز در این فرآیند شرکت داشتند. علاوه بر این، از آنجایی که سرویس mount می توانست از یک پورت دلخواه استفاده کند، پیکربندی فایروال بسیار پیچیده بود. در NFS 4، پروتکل های mount و port mapping حذف شده اند. علاوه بر این، قفل کردن در مشخصات پروتکل اصلی NFS گنجانده شد و پروتکل NLM (مدیر قفل شبکه) که در نسخه‌های قبلی NFS استفاده می‌شد، سرانجام منسوخ شد.
    ■ سیستم فایل NFS 4 نیاز به استفاده دارد پروتکل حمل و نقل، که توانایی تشخیص "ازدحام" در شبکه را فراهم می کند. این بدان معنی است که سرویس گیرندگان و سرورهای NFS به تدریج به جای UDP به TCP مهاجرت می کنند که معمولاً با NFS 3 استفاده می شود.
    ■ NFS 2 و NFS 3 به U.S. ASCII یا ISO Latin 1. هنگامی که یک کلاینت با استفاده از یک مجموعه کاراکتر یک فایل را ایجاد کرد و یک کلاینت با مجموعه کاراکترهای متفاوت به آن فایل دسترسی پیدا کرد، مشکلاتی ایجاد شد. NFS 4 از مجموعه کاراکترهای UTF-8 استفاده می کند که از فشرده سازی فشرده نویسه های 16 بیتی و 32 بیتی برای انتقال از طریق شبکه پشتیبانی می کند. علاوه بر این، مجموعه کاراکترهای UTF-8 حاوی اطلاعات کافی برای جلوگیری از ایجاد مشکل در هنگام ایجاد یک فایل با یک مجموعه کاراکتر و دسترسی به فایلی با مجموعه کاراکترهای متفاوت است.
    ■ سیستم فایل NFS 4 از مشتری می خواهد که توصیفگرهای فایل را به طور جداگانه مدیریت کند. در NFS 3، کلاینت می توانست دسته را به عنوان یک شی در حافظه پنهان نگه دارد، در حالی که سرور مراقب بود که دسته همیشه به یک فایل اشاره کند. NFS 4 دو نوع توصیفگر فایل را تعریف می کند. یکی از آنها توصیفگرهای فایل پایدار نامیده می‌شود و دارای قابلیت‌های توصیف‌کننده فایل NFS 3 است. دومی، توصیف‌گر فایل موقت، شامل انقضای یک توصیف‌گر فایل پس از یک دوره زمانی یا رویداد معین است. این یک ویژگی برای سرورهایی است که سیستم های فایل آنها (مانند NTFS) نمی توانند یک نقشه ثابت بین فایل های نقشه برداری شده و دسته ها ارائه دهند.
    ■ NFS 4 پشتیبانی از عملیات OPEN و CLOSE را اضافه می کند که معنای آن امکان تعامل با مشتریان CIFS را فراهم می کند. دستور OPEN داده های حالت را روی سرور ایجاد می کند.
    ■ پشتیبانی از یک درخواست OPEN در NFS 4 به مشتری اجازه می‌دهد تا درخواستی برای باز کردن فایلی که ساختاری مشابه درخواست‌های باز کردن برنامه‌های ویندوز دارد، صادر کند. انتخاب نیز پشتیبانی می شود. اشتراک گذاریفایل با سایر مشتریان یا دسترسی انحصاری به فایل.

    1.4.2.1 امنیت NFS 4

    سیستم فایل NFS 4 به شما اجازه می دهد تا امنیت داده های ذخیره شده را افزایش دهید. به طور خاص، NFS 4 برای ویژگی های فایل بیشتر پشتیبانی می کند. یکی از این ویژگی ها لیست کنترل دسترسی به سبک ویندوز NT (ACL) است. این باعث بهبود تعامل بین فایل سیستم ها و تقویت ساختار امنیتی می شود.
    در حالی که در NFS 2 و NFS 3 استفاده از ویژگی های امنیتی فقط توصیه می شد، در NFS 4 اجباری شد. سیستم فایل NFS 4 نیاز به پیاده سازی مکانیزم امنیتی با استفاده از رابط RPCSEC_GSS (سرویس های امنیتی عمومی) به طور کلی و پروتکل های Kerberos 5/LIPKEY به طور خاص دارد. توجه داشته باشید که RPCSEC_GSS فقط نقش را انجام می دهد رابط APIو یک مکانیسم حمل و نقل برای برچسب ها و داده های مرتبط با امنیت. سیستم فایل NFS 4 امکان احراز هویت و طرح های امنیتی متعدد و همچنین امکان انتخاب طرح مناسب برای کلاینت ها و سرورها را فراهم می کند.
    اجازه دهید کمی به مطالعه فناوری LIPKEY توجه کنیم که از ترکیبی از متقارن و رمزگذاری نامتقارن. کلاینت داده های کاربر و رمز عبور را با استفاده از یک کلید 128 بیتی تولید شده به صورت تصادفی رمزگذاری می کند. رمزگذاری با استفاده از یک الگوریتم متقارن انجام می شود، به عنوان مثال. برای رمزگشایی باید از همان کلید استفاده شود. از آنجایی که سرور برای رمزگشایی پیام ها به این کلید نیاز دارد، یک کلید به صورت تصادفی باید به سرور ارسال شود. کلاینت کلید (که به صورت تصادفی تولید می شود) را با آن رمزگذاری می کند کلید عمومیسرور سرور داده ها را با کلید خصوصی خود رمزگشایی می کند، کلید متقارن را استخراج می کند و داده های کاربر و رمز عبور را رمزگشایی می کند.
    کلاینت ها می توانند سرورها را با گواهی سرور احراز هویت کنند و از خدمات مرجع صدور گواهی برای تأیید گواهی استفاده می شود. یکی از روش های محبوب هک، رهگیری بسته های داده "خارجی" با ارسال بعدی آنها پس از یک دوره زمانی خاص است. هنگام استفاده از Kerberos، سیستم فایل NFS یک مهر زمانی به هر بسته اضافه می کند. سرور مُهرهای زمانی دریافتی اخیر را ثبت می‌کند و آنها را با مُهر زمانی بسته‌های RPC جدید مقایسه می‌کند. اگر مهرهای زمانی بسته‌ها قدیمی‌تر از دریافت‌های قبلی توسط سرور باشد، سرور بسته‌های دریافتی را نادیده می‌گیرد.

    1.5 هنگام استفاده از چندین پروتکل به مشکلات دسترسی پیدا کنید

    چندین شرکت شروع به ارائه سیستم هایی کردند که به طور همزمان از CIFS، NFS و سایر مشتریان سیستم فایل شبکه پشتیبانی می کنند. فروشندگان تلاش زیادی برای غلبه بر مشکلات فنی که ناشی از استفاده بالقوه از سیستم‌های عامل و فایل مختلف توسط مشتریان است، انجام داده‌اند. توجه داشته باشید که مشکلات مربوط به خود داده ها نیست، بلکه مربوط به متادیتای فایل ها است. یک آزمایش ساده برای چنین مشکلاتی کپی کردن فایل از سرور به مشتری و بازگشت به سرور (یا برعکس) است. پس از قرار دادن فایل در منبع اصلی، ابرداده باید حاوی مقادیر پایه باشد، یعنی. مجوزهای فایل و مُهرهای زمانی نباید تغییر کند. اگر این درست نیست، پس مشکل شناسایی شده است.
    در زیر نمونه هایی از برخی مشکلات فنی احتمالی آورده شده است.
    ■ سیستم عامل های مختلف از روش های مختلفی برای ردیابی مجوزهای دسترسی کاربر و گروه استفاده می کنند.
    ■ سیستم عامل ها و فایل سیستم های مختلف معنایی متفاوت برای باز کردن و قفل کردن فایل ها دارند.
    ■ قراردادهای نامگذاری فایل به روش های مختلفی انجام می شود. سیستم های فایل مختلف حداکثر اندازه نام فایل، مقدار حروف کوچک نام فایل و مجموعه کاراکترهای مجاز در نام فایل ها را متفاوت نشان می دهند.
    ■ داده ها و ساختار آن در سیستم های فایل مختلف متفاوت است. به عنوان مثال، برخی از سیستم‌های فایل دو مهر زمانی را ردیابی می‌کنند، در حالی که برخی دیگر از سه مُهر زمانی (زمانی که فایل آخرین دسترسی، آخرین تغییر، و ایجاد فایل) انجام شده است. حتی اگر هر دو سیستم فایل دو مهر زمانی را دنبال کنند، واحدها ممکن است متفاوت باشند. مثال دیگر واحدهای افست در فایل ها است. برخی از سیستم های فایل از افست های 32 بیتی پشتیبانی می کنند، در حالی که برخی دیگر از افست های 16 یا 64 بیتی پشتیبانی می کنند.
    ■ مشکلات مربوط به آدرس دهی قفل های نقشه برداری شده. سرور CIFS قفل را اعمال می کند: اگر یک کلاینت منطقه ای از فایل را قفل کرده باشد، هر گونه عملیات نوشتن در آن ناحیه از فایل توسط کلاینت دیگر منجر به خطا می شود. با این حال، قفل اجباری توسط سرورهای NFS پشتیبانی نمی شود. بنابراین، شما باید انتخاب کنید که آیا قفل اجرا شود یا خیر، که باعث می شود یک پیام خطا به مشتری NFS ارسال شود.

    کنستانتین پیانزین

    ویژگی های اصلی سیستم فایل NFS در پلت فرم یونیکس.

    خوشبختی زمانی است که خواسته های ما با توانایی های دیگران مطابقت داشته باشد.

    "ورمچکو"

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

    سیستم عامل یونیکس در حال حاضر یک نوع رنسانس را تجربه می کند که عمدتاً به دلیل افزایش علاقه به سیستم عامل لینوکس رایگان است. در همان زمان، نسخه‌های مختلف ویندوز در رایانه‌های رومیزی استفاده می‌شود، در درجه اول Windows 9x و Windows NT/2000، اگرچه طعم‌های آزادانه یونیکس در اینجا نیز به آرامی شهروندی پیدا می‌کنند.

    برای بسیاری از سازمان ها، میزبانی سرویس فایل شبکه بر روی کامپیوترهای یونیکس راه حل بسیار جذابی است، مشروط بر اینکه چنین سرویسی از عملکرد و قابلیت اطمینان کافی برخوردار باشد. با توجه به تفاوت‌های فراوان بین سیستم‌های فایل یونیکس و ویندوز، عمدتاً در طرح‌های نام‌گذاری فایل‌ها، مجوزها، قفل‌ها و تماس های سیستمیهنگام دسترسی به فایل ها، اطمینان از شفافیت دسترسی در یک محیط ناهمگن UNIX/Windows از اهمیت ویژه ای برخوردار است. علاوه بر این، غیر معمول نیست که سرورهای فایل یونیکس به عنوان یک افزونه به موجود نصب شوند سرورهای ویندوز NT و Netware.

    برای سیستم عامل یونیکس، تمامی سیستم‌های فایل شبکه کم و بیش محبوب، از جمله سیستم‌هایی که در شبکه‌های مایکروسافت (SMB)، NetWare (NCP)، مکینتاش (AFP) استفاده می‌شوند، اجرا می‌شوند. البته شبکه های یونیکس پروتکل های مخصوص به خود را دارند، در درجه اول NFS و DFS. به خاطر داشته باشید که هر سرور یونیکس می تواند خدمات NFS و SMB (و همچنین NCP و AFP) را ارائه دهد و در نتیجه هنگام ایجاد زیرساخت شبکه، انعطاف بیشتری را ارائه دهد.

    با وجود تنوع سیستم های فایل شبکه یونیکس، رهبران بلامنازع NFS (سیستم فایل شبکه، ترجمه تحت اللفظی - سیستم فایل شبکه) و SMB (بلاک پیام سرویس) هستند. این مقاله بر روی قابلیت های NFS تمرکز خواهد کرد. در عین حال در یکی از شماره های بعدی قصد داریم ویژگی های SMB را بر روی پلتفرم یونیکس و در درجه اول محصول سامبا را در نظر بگیریم که در شبکه های یونیکس/ویندوز به خوبی خود را ثابت کرده است.

    نسخه های NFS

    اولین پیاده سازی سیستم فایل شبکه NFS توسط Sun Microsystems در سال 1985 توسعه یافت. از آن زمان، NFS در جهان یونیکس گسترش یافته است، با نصب ده ها میلیون نفر. علاوه بر یونیکس، سیستم NFS به عنوان یک پلتفرم سرور در سیستم عامل های VMS، MVS و حتی ویندوز کاربرد پیدا کرده است.

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

    در حال حاضر، NFS با نسخه دوم و سوم ارائه می شود (نسخه اول NFS هرگز در بازار ظاهر نشد). با وجود تعدادی محدودیت، NFS v2 بسیار محبوب است. این اوست که بخشی از یونیکس آزادانه توزیع شده (به ویژه لینوکس) و همچنین برخی از یونیکس های تجاری است.

    نسخه سوم NFS در اواسط دهه 90 با تلاش مشترک Sun، IBM، Digital و سایر شرکت ها به منظور بهبود عملکرد، امنیت و سهولت مدیریت سیستم فایل شبکه توسعه یافت. NFS v3 با مشخصات NFS قبلی سازگار است، به این معنی که یک سرور NFS v3 می تواند نه تنها به کلاینت های NFS v3، بلکه به کلاینت های NFS v2 نیز سرویس دهد.

    با وجود حضور نسبتا طولانی خود در بازار، NFS v3 هنوز از نظر تعداد نصب از NFS v2 پایین تر است. با توجه به این ملاحظات، ابتدا به ویژگی های اصلی NFS v2 می پردازیم و سپس با نوآوری های نسخه سوم NFS آشنا می شویم.

    به خاطر داشته باشید که پیاده سازی های خاص یک نسخه از NFS ممکن است کمی با یکدیگر متفاوت باشند. تفاوت ها اول از همه به ترکیب شیاطین، نام ها، مکان و نام آنها مربوط می شود. فایل های پیکربندی NFS. علاوه بر این، پیاده سازی NFS به قابلیت ها و ویژگی های خود یونیکس بستگی دارد. به عنوان مثال، NFS v2 از ACL ها پشتیبانی می کند، اما فقط در قالب های یونیکس که چنین پشتیبانی در هسته وجود دارد. بنابراین، هنگام توصیف NFS، کلی ترین مورد را در نظر خواهیم گرفت.

    پروتکل های NFS V2

    شکل 1 مدل شبکه NFS v2 را با توجه به مرجع نشان می دهد مدل OSI. بر خلاف اکثر سرویس های شبکه TCP/IP، NFS به صراحت از پروتکل های لایه نمایش و جلسه استفاده می کند. NFS بر اساس مفهوم فراخوانی از راه دور (RPC) است. بر اساس این مفهوم، هنگام دسترسی به یک منبع راه دور (به عنوان مثال، یک فایل)، یک برنامه در رایانه محلی یک فراخوانی سیستمی معمولی را انجام می دهد (مثلاً یک فراخوانی عملکرد باز فایل) را انجام می دهد، اما در واقع این روش از راه دور - در سرور منبع اجرا می شود. در این حالت، فرآیند کاربر قادر به تعیین اینکه تماس به صورت محلی یا از راه دور انجام می شود، نیست. پس از اینکه فرآیند به منبعی در یک کامپیوتر راه دور که به عنوان سرور عمل می کند دسترسی پیدا می کند، هسته یا یک شبح سیستم خاص آرگومان های رویه را به همراه شناسه خود در یک بسته شبکه بسته بندی می کند، یک جلسه ارتباطی با سرور باز می کند و این بسته را به آن ارسال می کند. سرور بسته دریافتی را باز می کند، رویه و آرگومان های درخواستی را تعیین می کند و سپس رویه را اجرا می کند. سپس سرور کد بازگشتی رویه را برای مشتری ارسال می کند که آن را به فرآیند کاربر ارسال می کند. بنابراین، RPC کاملاً با لایه نشست مدل OSI سازگار است.

    یک سوال منصفانه مطرح می شود: چرا مدل شبکه NFS به پروتکل لایه ارائه ویژه نیاز دارد؟ واقعیت این است که Sun محتاطانه روی استفاده از NFS در شبکه‌های ناهمگن حساب می‌کرد، جایی که رایانه‌ها دارای معماری‌های مختلف سیستم هستند، از جمله ترتیب بایت‌های مختلف در یک کلمه ماشین، نمایش متفاوت اعداد ممیز شناور، مرزهای تراز ساختار ناسازگار، و غیره. به این ترتیب، از پروتکل نمایش داده های خارجی (EXternal Data Representation، XDR) استفاده می شود. این به اصطلاح شکل متعارف نمایش داده را توصیف می کند که به معماری سیستم پردازنده بستگی ندارد. هنگام انتقال بسته‌های RPC، کلاینت داده‌های محلی را به شکل متعارف تبدیل می‌کند و سرور برعکس عمل می‌کند. توجه داشته باشید که فرم XDR متعارف مطابق با نمایش داده‌ای است که برای خانواده پردازنده‌های SPARC و Motorola اتخاذ شده است. در سرورهایی که شکل مشابهی از نمایش داده ها اجرا می شود، این به شما امکان می دهد در موارد دسترسی شدید به سرور فایل، به مزیت عملکردی (هر چند به احتمال زیاد میکروسکوپی) نسبت به رقبا دست پیدا کنید.

    در NFS v2، UDP به عنوان پروتکل انتقال انتخاب شد. توسعه دهندگان این را با این واقعیت توضیح می دهند که جلسه RPC مدت زمان کوتاهی طول می کشد. علاوه بر این، از نقطه نظر اجرای رویه های از راه دور، هر بسته RPC خودکفا است، یعنی هر بسته حاوی اطلاعات کاملی در مورد کارهایی که باید روی سرور انجام شود یا در مورد نتایج رویه است. سرویس‌های RPC معمولاً وضعیت اتصال را ردیابی نمی‌کنند (بدون اتصال)، یعنی سرور اطلاعاتی را در مورد درخواست‌های مشتری در گذشته ذخیره نمی‌کند: به عنوان مثال، آخرین باری که مشتری داده‌ها را خوانده از کجا در فایل است. برای یک سیستم فایل شبکه، این یک مزیت قابل اطمینان قطعی است، زیرا مشتری می تواند بلافاصله پس از راه اندازی مجدد سرور، عملیات فایل را ادامه دهد. اما این طرح هنگام نوشتن و قفل کردن فایل ها مملو از مشکلات است و برای دور زدن آنها، توسعه دهندگان NFS مجبور شدند از راه حل های مختلفی استفاده کنند (استفاده از UDP مجموعه دیگری از مشکلات خاص را ایجاد می کند، اما بعداً به آنها خواهیم پرداخت).

    یک تفاوت مهم بین سرویس های RPC موجود با NFS و سایر سرویس های سرور شبکه این است که از inetd superdaemon استفاده نمی کنند. سرویس‌های شبکه معمولی، مانند telnet یا rlogin، معمولاً در هنگام راه‌اندازی سیستم به‌عنوان دیمون راه‌اندازی نمی‌شوند، اگرچه این کار ممنوع نیست. بیشتر اوقات، آنها از به اصطلاح inetd superdaemon استفاده می کنند که به پورت های نرم افزاری پروتکل های TCP و UDP "گوش می دهد". سرویس ها در فایل پیکربندی superdaemon (معمولا /etc/inetd.conf) تعریف می شوند. پس از دریافت درخواست برای پورت نرم افزاردر سمت مشتری، inetd فرآیند مناسب را در کودکی آغاز می کند خدمات شبکه(به عنوان مثال، in.rlogind)، که درخواست را پردازش می کند.

    سرویس‌های RPC از inetd super daemon استفاده نمی‌کنند، زیرا همانطور که قبلاً ذکر شد، یک جلسه RPC زمان بسیار کوتاهی دارد، در واقع فقط در طول پردازش یک درخواست واحد. یعنی برای هر درخواست، inetd مجبور می‌شود یک فرآیند فرزند جدید از سرویس RPC را شروع کند که برای یونیکس بسیار گران است. به دلایل مشابه، یک فرآیند RPC نمی تواند فرآیندهای جدید ایجاد کند و نمی تواند چندین درخواست را به صورت موازی ارائه دهد. بنابراین، سرویس‌های RPC به‌عنوان نمونه‌های شبح همزمان چندگانه برای بهبود عملکرد اجرا می‌شوند. در عین حال، تعداد نمونه‌های یک دیمون خاص ارتباط مستقیمی با تعداد مشتریان ندارد. حتی یک دیمون می تواند به بسیاری از مشتریان سرویس دهد، اما در زمانی که قادر به پردازش یک درخواست واحد باشد، بقیه در صف قرار می گیرند.

    تفاوت مهم دیگر بین سرویس های RPC و سرویس های شبکه معمولی این است که از پورت های نرم افزاری UDP از پیش تعریف شده استفاده نمی کنند. در عوض، از یک سیستم ترجمه پورت به اصطلاح portmapper استفاده می شود. برای پشتیبانی از آن، یک شبح پورت مپ ویژه در هنگام بوت شدن سیستم مقداردهی اولیه می شود. در سیستم ترجمه پورت، به هر سرویس RPC یک شماره برنامه، شماره نسخه، شماره رویه و پروتکل (UDP یا TCP) اختصاص داده می شود. شماره برنامه به طور منحصر به فرد یک سرویس RPC خاص را شناسایی می کند. رابطه بین نام سرویس RPC و شماره برنامه را می توان از محتویات فایل /etc/rpc مشاهده کرد. هر برنامه RPC از مجموعه ای از رویه ها پشتیبانی می کند که با شماره آنها مشخص می شوند. اعداد رویه را می توان در فایل های هدر مربوطه یافت: به عنوان مثال، برای سرویس NFS، آنها در فایل /usr/include/nfs/nfs.h مشخص شده اند.

    به طور خاص، سرویس NFS دارای شماره برنامه 100003 است و شامل رویه هایی مانند "باز کردن فایل"، "بلاک خواندن"، "ایجاد فایل" و غیره است. هنگام فراخوانی رویه های راه دور، شماره برنامه سرویس، شماره رویه و شماره نسخه به همراه آرگومان های رویه در بسته RPC ارسال می شود. شماره نسخه برای شناسایی قابلیت های سرویس استفاده می شود. واقعیت این است که توسعه دهندگان به طور مداوم خدمات NFS را با هر کدام بهبود می بخشند یک نسخه جدیدکاملاً به عقب با موارد قبلی سازگار است.

    اصل عملکرد مترجم portmap بسیار ساده است. هنگامی که هر سرویس RPC را مقداردهی اولیه می کنید (به ویژه در زمان بوت شدن سیستم عامل)، با استفاده از شبح portmap ثبت می شود. هنگامی که روی سرور راه اندازی می شود، سرویس RPC به دنبال یک پورت نرم افزاری خالی می گردد، آن را برای خود ذخیره می کند و شماره پورت را به شبح portmap گزارش می دهد. برای برقراری ارتباط با یک سرور، یک کلاینت RPC باید ابتدا به پورت مپ سرور نگاه کند و از آن بپرسد که کدام پورت نرم افزاری توسط یک سرویس RPC خاص روی سرور اشغال شده است. فقط در این صورت مشتری می تواند مستقیماً با خدمات تماس بگیرد. در برخی موارد، کلاینت به طور غیر مستقیم با سرویس مورد نظر ارتباط برقرار می کند، یعنی ابتدا با شبح portmap تماس می گیرد، که سرویس RPC را از طرف مشتری درخواست می کند. برخلاف خدمات RPC، مترجم پورت مپ همیشه به پورت 111 از پیش تعریف شده متصل می شود، بنابراین مشتری به روش استاندارد با پورت مپ ارتباط برقرار می کند.

    COMPOSITION NFS V2

    به طور کلی سرور NFS علاوه بر پورت مپ شامل daemons rpc.mountd، nfsd، rpc.lockd، rpc.statd می باشد. یک کلاینت NFS که بر روی پلتفرم یونیکس اجرا می شود، باید دارای شیاطین بایود (اختیاری)، rpc.lockd و rpc.statd در حال اجرا باشد.

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

    شبح rpc.mountd درخواست های کلاینت را برای نصب سیستم های فایل مدیریت می کند. سرویس mount به عنوان یک شبح جداگانه پیاده سازی می شود زیرا پروتکل mount بخشی از NFS نیست. این به این دلیل است که عملیات mount ارتباط نزدیکی با نحو نام فایل دارد و اصول نامگذاری فایل ها بین UNIX و مثلا VMS متفاوت است.

    دیمون nfsd درخواست های NFS RPC را می پذیرد و سرویس می دهد. اجرای چندین نمونه از nfsd روی سرور برای بهبود عملکرد معمول است.

    شبح rpc.lockd که هم روی کلاینت و هم روی سرور اجرا می‌شود، به قفل کردن فایل‌ها اختصاص داده شده است، در حالی که شبح rpc.statd (همچنین روی سرور و کلاینت اجرا می‌شود) آمار قفل را در صورت نیاز به بازیابی خودکار در صورت خرابی سرویس NFS حفظ می‌کند.

    دیمون biod که روی کلاینت اجرا می‌شود، هم قادر به خواندن پیش‌خوان و هم عملیات نوشتن پشت است، که عملکرد را تا حد زیادی بهبود می‌بخشد. اما وجود بیود برای کار مشتری الزامی نیست. برای بهبود بیشتر عملکرد در ماشین کلاینت، می توان چندین شبح بیود را بارگذاری کرد.

    دیمون دیگری که بر روی سرور اجرا می شود مسئول احراز هویت و خدمات چاپ برای سرویس گیرندگان DOS/Windows است، در برخی از سیستم ها pcnfsd و در برخی دیگر in.pcnfsd نامیده می شود.

    علاوه بر این، بسته NFS شامل ابزارهای مختلف سیستم و برنامه های تشخیصی (showmount، rpcinfo، exportfs، nfsstat) است.

    قوانین صادرات

    سیستم های فایل و دایرکتوری هایی که کلاینت ها می توانند از راه دور روی سرور NFS نصب کنند باید به صراحت مشخص شوند. این رویه در NFS «صادرات» منابع نامیده می شود. در عین حال، یک سرور NFS، بر خلاف مثلاً یک سرور SMB، فهرستی از منابع صادر شده خود را پخش نمی کند. با این حال، مشتری ممکن است چنین لیستی را از سرور درخواست کند. در سمت سرور، شبح rpc.mountd مسئول سرویس درخواست‌های مانت است.

    صادرات اشتراک فایل NFS از چهار قانون اساسی پیروی می کند.

    1. فایل سیستم را می توان به صورت کلی یا در بخش هایی که دایرکتوری ها و فایل ها هستند صادر کرد. به خاطر داشته باشید که بزرگترین واحد صادر شده سیستم فایل است. اگر یک سیستم فایل (/usr/bin) در زیر سیستم فایل دیگر (/usr) روی سرور نصب شده باشد، صادر کردن سیستم /usr روی سیستم /usr/bin / تاثیری نخواهد داشت.
    2. شما فقط می توانید منابع فایل محلی را صادر کنید، به عبارت دیگر، اگر یک سیستم فایل خارجی روی سرور نصب شده باشد، یعنی در سرور دیگری قرار گرفته باشد، آنگاه نمی توان آن را دوباره صادر کرد.
    3. شما نمی توانید زیرشاخه های یک فایل سیستم از قبل صادر شده را صادر کنید، مگر اینکه آنها سیستم های فایل جداگانه باشند.
    4. شما نمی توانید دایرکتوری های والد یک دایرکتوری از قبل صادر شده را صادر کنید، مگر اینکه دایرکتوری والد یک سیستم فایل مستقل باشد.

    هر گونه نقض این قوانین منجر به خطا در عملکرد NFS می شود.

    جدول منابع صادر شده در فایل /etc/exports قرار دارد. متأسفانه، سینتکس این فایل مختص یونیکس است، بنابراین از Solaris به عنوان مثال استفاده می کنیم. فایل /etc/exports از خطوط متنی با فرمت زیر تشکیل شده است:

    -

    برخی از محبوب‌ترین گزینه‌ها در جدول 1 فهرست شده‌اند. در واقع، گزینه‌ها حقوق دسترسی به منابع صادر شده توسط مشتریان را توصیف می‌کنند. مهم است که به خاطر داشته باشید که مجوزهای فهرست شده در حین صادرات به هیچ وجه مجوزهایی را که در خود سیستم فایل اعمال می شود لغو نمی کند. به عنوان مثال، اگر سیستم فایل به صورت قابل نوشتن صادر شود و یک فایل خاص فقط خواندنی باشد، تغییر آن امکان پذیر نخواهد بود. بنابراین، هنگام صادرات، حقوق دسترسی به عنوان یک فیلتر اضافی عمل می کند. علاوه بر این، اگر مثلاً سیستم فایل با گزینه ro (فقط خواندنی) صادر شود، مشتری حق دارد آن را با گزینه rw (خواندن / نوشتن) نصب کند، اما تلاش برای نوشتن منجر به پیام خطا می شود.

    گزینه دسترسی به شما اجازه می دهد تا میزبان هایی را با مجوز نصب منبع مشخص کنید. بر این اساس، هیچ میزبان دیگری، به جز موارد ذکر شده در آن، قابلیت مانت و در نتیجه انجام عملیات بر روی منبع را ندارد.

    لیست هاست هایی که می توانند اطلاعات بنویسند با گزینه rw مشخص می شود. اگر لیست هاست ها در گزینه rw مشخص نشده باشد، هر میزبانی حق نوشتن دارد.

    گزینه root به شما این امکان را می دهد که میزبانی را مشخص کنید که در آن ابرکاربران ریشه محلی، امتیازات ریشه سرور را در منبع صادر شده دریافت می کنند. در غیر این صورت، حتی اگر به هاست حقوق rw داده شود، کاربر ریشه روی آن با کاربر nobody (uid=-2) برابر می شود، یعنی به کاربری با حداقل حقوق دسترسی. موارد فوق به طور خاص در مورد حقوق دسترسی به منبع راه دور اعمال می شود و بر حقوق دسترسی به منابع محلی مشتری تأثیری نمی گذارد.

    هنگام توصیف طرح احراز هویت NFS، گزینه های anon و امن مورد بحث قرار خواهند گرفت.

    قوانین نصب

    در حالی که برای سرور، منابع صادر شده می توانند به عنوان یک سیستم فایل یا یک دایرکتوری جداگانه عمل کنند، سپس برای کلاینت آنها همیشه مانند سیستم فایل به نظر می رسند. از آنجایی که پشتیبانی NFS در هسته یونیکس تعبیه شده است، عملیات نصب فایل سیستم های NFS توسط ابزار نصب استاندارد انجام می شود (برای نصب NFS نیازی به شبح جداگانه ای نیست) و فقط باید قید شود که سیستم فایل در حال نصب NFS باشد. راه دیگر برای نصب فایل /etc/fstab (/etc/filesystems در برخی از نسخه‌های یونیکس) است. در این مورد، سیستم های NFS راه دور (و همچنین محلی) در مرحله بوت سیستم عامل نصب می شوند. نقاط اتصال می توانند هر کدام باشند، از جمله به عنوان بخشی از سایر سیستم های فایل NFS، به عنوان مثال، سیستم های NFS می توانند روی هم قرار گیرند.

    گزینه های اصلی نصب NFS در جدول 2 فهرست شده است.

    گزینه bg امکان نصب در پس زمینه را به شما می دهد که در این صورت می توانید سایر دستورات mount را اجرا کنید.

    چند گزینه سخت/نرم بسیار جالب به نظر می رسند. با مانت "سخت"، کلاینت سعی می کند سیستم فایل را بدون توجه به هر چیزی مانت کند. اگر سرور از کار بیفتد، این باعث می‌شود که کل سرویس NFS به حالت تعلیق درآید. از نقطه نظر فرآیندهای کاربر، سیستم فایل مانند یک دیسک محلی بسیار کند به نظر می رسد. هنگامی که سرور به حالت کار برمی‌گردد، سرویس NFS به عملکرد خود ادامه می‌دهد انگار هیچ اتفاقی نیفتاده است. استفاده از گزینه intr به سیگنال سیستم INTERRUPT اجازه می دهد تا فرآیند نصب سخت را متوقف کند.

    با نصب نرم، سرویس گیرنده NFS چندین بار تلاش می کند تا به سرور متصل شود، همانطور که توسط گزینه های retans و timeo مشخص شده است (برخی از سیستم ها نیز از یک گزینه ویژه مجدد پشتیبانی می کنند). اگر سرور پاسخ ندهد، سیستم پیغام خطا صادر می کند و تلاش برای نصب را متوقف می کند. از نقطه نظر منطق عملیات فایل، هنگامی که یک سرور از کار می افتد، یک Soft Mount یک خرابی دیسک محلی را شبیه سازی می کند. اگر گزینه retrans (تلاش مجدد) مشخص نشده باشد، تعداد دفعات تکرار به مقدار پیش فرض این سیستم یونیکس محدود می شود. گزینه‌های retrans و timeo نه تنها برای مانت‌ها، بلکه برای هر عملیات RPC انجام شده در سیستم فایل NFS اعمال می‌شود. یعنی اگر کلاینت عملیات نوشتن را انجام دهد و در آن زمان شبکه یا سرور از کار بیفتد، کلاینت سعی می کند درخواست ها را دوباره امتحان کند.

    به این سوال که کدام یک از حالت های "نرم" یا "سخت" بهتر است، نمی توان بدون ابهام پاسخ داد. اگر داده‌های روی سرور باید در زمانی که موقتاً از کار می‌افتد سازگار باشند، نصب «سخت» ترجیح داده می‌شود. این حالت همچنین در مواردی که سیستم های فایل نصب شده حاوی برنامه ها و فایل هایی هستند که برای کارکرد مشتری حیاتی هستند، به ویژه برای ماشین های بدون دیسک ضروری است. در موارد دیگر، به‌ویژه زمانی که صحبت از سیستم‌های فقط خواندنی می‌شود، به نظر می‌رسد که حالت soft mount ارجح‌تر است.

    احراز هویت و امنیت

    همانطور که قبلا ذکر شد، هر بسته RPC مستقل است. علاوه بر این ، به طور کلی ، NFS حالتی را ارائه نمی دهد ، یعنی سابقه ای از درخواست هایی که قبلاً توسط مشتریان انجام شده است را حفظ نمی کند و همچنین کار مشتریان را ردیابی نمی کند. بنابراین، در سیستم‌هایی که از تماس‌های رویه از راه دور استفاده می‌شود، مشکل امنیتی بسیار مرتبط است.

    در NFS، احراز هویت منحصراً در مرحله نصب فایل سیستم و تنها بر اساس نام دامنه (یا آدرس IP) ماشین سرویس گیرنده انجام می شود. یعنی اگر یک سرویس گیرنده NFS (در اینجا منظور ما یک کامپیوتر است، نه کاربر کامپیوتر) با یک درخواست mount به سرور دسترسی پیدا کند، سرور حقوق دسترسی را از جدول /etc/exports تعیین می کند، در حالی که کلاینت با نام (آدرس IP) کامپیوتر شناسایی می شود. اگر مشتری مجاز باشد عملیات خاصی را روی منبع صادر شده انجام دهد، یک "عدد جادویی" معین (کوکی جادویی) به مشتری گزارش می شود. سپس مشتری باید این شماره را در هر درخواست RPC برای اثبات اعتبار خود لحاظ کند.

    اینجا، در واقع، کل مجموعه ساده ابزارهای احراز هویت مشتری است، اما کاربران به هیچ وجه احراز هویت نمی شوند. با این حال، هر درخواست RPC شامل uid کاربر است که درخواست را آغاز کرده است و لیستی از شناسه های گروه، gid، که کاربر به آن تعلق دارد. اما این شناسه ها برای احراز هویت استفاده نمی شوند، بلکه برای تعیین حقوق دسترسی یک کاربر خاص به فایل ها و دایرکتوری ها استفاده می شوند.

    توجه داشته باشید که uid و gid در سمت کلاینت تعریف شده اند نه سمت سرور. بنابراین، مدیران با مشکل هماهنگ کردن محتویات /etc/passwd (و /etc/group) بین کلاینت‌ها و سرورهای NFS مواجه می‌شوند تا به کاربر Vasya روی سرور، حقوق کاربر Petya اختصاص داده نشود. برای شبکه های بزرگ، این مشکلات جدی ایجاد می کند. برای اطمینان از سازگاری پایگاه داده کاربر و همچنین فایل‌های سیستمی مانند /etc/hosts، /etc/rpc، /etc/services، /etc/protocols، /etc/aliases و غیره، می‌توانید از سیستم اطلاعات شبکه (NIS)، که توسط Sun در سال 1985 توسعه یافته و در اکثر نسخه‌های UNIX یافت می‌شود، استفاده کنید (نسخه‌های NIS پیشرفته‌تر است). NIS یک سرویس اطلاعاتی است که در اولین تقریب شبیه سرویس دایرکتوری ویندوز NT است و به شما امکان ذخیره و پردازش مرکزی را می دهد. فایل های سیستمی. به هر حال، NIS بر اساس همان اصل NFS ساخته شده است، به ویژه، از پروتکل های RPC و XDR استفاده می کند.

    یکی دیگر از ویژگی های مهم NFS این است که لیستی از gid کاربر در هر درخواست RPC ارسال می شود. برای محدود کردن اندازه بسته RFC، اکثر پیاده‌سازی‌های NFS تعداد گروه‌ها را به بیش از 8 یا 16 محدود می‌کنند. اگر کاربر عضو گروه‌های بیشتری باشد، این امر می‌تواند منجر به خطا در تعیین حقوق دسترسی روی سرور شود. این مشکل برای سرورهای فایل شرکتی بسیار مرتبط است. یک راه حل اساسی استفاده از ACL است، اما متأسفانه همه طعم های یونیکس از آنها پشتیبانی نمی کنند.

    سیستم احراز هویت پذیرفته شده در NFS بسیار ضعیف است و ارائه نمی دهد حفاظت قابل اعتماد. هر کسی که با NFS سروکار داشته باشد می داند که دور زدن سیستم امنیتی آن چقدر آسان است. برای انجام این کار، حتی نیازی به استفاده از روش های جعل آدرس های IP (IP-spoofing) یا نام ها (DNS-spoofing) نیست. کافی است یک مهاجم "شماره جادویی" را رهگیری کند و در آینده بتواند اقداماتی را از طرف مشتری انجام دهد. علاوه بر این، "شماره جادویی" تا راه اندازی مجدد سرور بعدی تغییر نمی کند.

    در بسیاری از سرورهای اینترنتی، می‌توانید راه‌های دیگری از جمله راه‌های بسیار عجیب و غریب برای کرک کردن NFS بیابید. تعداد «حفره‌های» کشف‌شده هزاران است. بنابراین توصیه می شود NFS v.2 فقط در داخل شبکه های امن استفاده شود.

    بر اساس این ملاحظات، Sun پروتکل SecureRPC را با استفاده از کلیدهای رمزگذاری نامتقارن و متقارن توسعه داد. در عین حال، از روش های رمزنگاری برای احراز هویت نه تنها میزبان ها، بلکه کاربران نیز استفاده می شود. با این حال، خود داده ها رمزگذاری نشده اند. متأسفانه، به دلیل محدودیت های صادراتی دولت ایالات متحده، همه یونیکس ها با پشتیبانی SecureRPC عرضه نمی شوند. بنابراین، ما در مورد قابلیت های این پروتکل کوتاه نمی آییم. با این حال، اگر نسخه یونیکس شما از SecureRPC پشتیبانی می کند، کتاب هال اشتاین "مدیریت NFS و NIS" توسط O'Reilly & Associates کمک ارزشمندی در راه اندازی آن خواهد بود.

    مشکل دیگر مربوط به کلاینت های NFS در پلتفرم های MS-DOS و Windows 3.x/9x است. این سیستم ها تک کاربره هستند و با استفاده از ابزارهای NFS معمولی نمی توان کاربر را شناسایی کرد. برای اهداف احراز هویت کاربران DOS/Windows، شبح pcnfsd روی سرور راه اندازی می شود. هنگام اتصال (نصب) درایوهای NFS بر روی یک ماشین کلاینت، نام کاربری و رمز عبور می خواهد که نه تنها امکان شناسایی، بلکه احراز هویت کاربران را نیز فراهم می کند.

    اگرچه ویندوز NT یک سیستم عامل چند کاربره است، پایگاه داده کاربر و طرح احراز هویت کاربر با سیستم عامل یونیکس ناسازگار است. بنابراین، کلاینت های NFS مبتنی بر ویندوز NT نیز مجبور به استفاده از قابلیت های pcnfsd هستند.

    علاوه بر احراز هویت کاربر، pcnfs امکان چاپ یونیکس را از سایت های سرویس گیرنده DOS/Windows می دهد. درست است، ویندوز NT در ابتدا شامل برنامه LPR.EXE است که به شما امکان چاپ روی سرورهای یونیکس را نیز می دهد.

    برای دسترسی به سرویس های فایل و NFS در ماشین های DOS/Windows، باید نرم افزار مشتری ویژه ای را نصب کنید و این محصولات بسیار گران هستند.

    با این حال، اجازه دهید به گزینه های صادرات فایل های NFS برگردیم (جدول 1 را ببینید). در صورتی که کاربر DOS/Windows نتواند خود را احراز هویت کند (با توجه به رمز عبور اشتباه) یا زمانی که کاربر میزبان متصل شده از طریق SecureRPC احراز هویت نشده باشد، گزینه anon uid شناسه کاربر را مشخص می کند. به طور پیش فرض، anon دارای uid=-2 است.

    زمانی که از پروتکل SecureRPC استفاده می شود از گزینه safe استفاده می شود.

    ویژگی های معماری NFS V2

    سیستم های فایل NFS باید از دو شرط پیروی کنند (به هر حال، این الزامات نه تنها برای NFS، بلکه برای سایر سیستم های فایل شبکه نیز اعمال می شود).

    1. از نقطه نظر برنامه های کاربر مشتری، سیستم فایل NFS، همانطور که بود، بر روی آن قرار دارد دیسک محلی. برنامه ها هیچ راهی برای تشخیص فایل های NFS از فایل های معمولی ندارند.
    2. سرویس گیرنده NFS قادر به تعیین پلتفرم مورد استفاده به عنوان سرور نیست. این می تواند UNIX، MVS و حتی ویندوز NT باشد. تفاوت در معماری سرور فقط بر سطح عملیات خاص تأثیر می گذارد و نه از نظر قابلیت های NFS. برای مشتری ساختار فایل NFS مشابه یک سیستم محلی است.

    اولین سطح شفافیت با استفاده از سیستم فایل مجازی یونیکس (Virtual File System، VFS) به دست می آید. VFS مسئول تعامل نه تنها با NFS، بلکه با سیستم های محلی مانند UFS، ext2، VxFS و غیره است.

    سطح دوم شفافیت از طریق استفاده از به اصطلاح گره های مجازی (گره های مجازی، vnodes) ارائه می شود که ساختار آنها می تواند با inode ها در سیستم های فایل یونیکس مرتبط باشد.

    عملیات روی فایل سیستم های NFS عملیات VFS هستند، در حالی که تعامل با فایل ها و دایرکتوری های فردی توسط عملیات vnode تعریف می شود. پروتکل RPC از NFS v2 16 رویه مربوط به عملیات نه تنها روی فایل‌ها و دایرکتوری‌ها، بلکه در مورد ویژگی‌های آن‌ها را توصیف می‌کند. درک این نکته مهم است که فراخوانی های RPC و رابط vnode مفاهیم متفاوتی هستند. رابط های vnode خدمات سیستم عامل را برای دسترسی به سیستم های فایل، چه محلی و چه از راه دور، تعریف می کنند. RPC از NFS یک پیاده سازی خاص از یکی از رابط های vnode است.

    عملیات خواندن/نوشتن در سمت سرویس گیرنده ذخیره می شود، یعنی کلاینت محتویات فایل ها و دایرکتوری ها را در حافظه پنهان ذخیره می کند. به طور معمول، اندازه بافر کش NFS 8 کیلوبایت است. اگر دیمون‌های biod روی مشتری اجرا می‌شوند، خواندن زودتر از موعد انجام می‌شود و نوشتن در حالت تنبلی انجام می‌شود. به عنوان مثال، اگر یک فرآیند کاربر اطلاعاتی را بنویسد، سپس داده ها در بافر کش انباشته می شوند و تنها پس از آن ارسال می شوند، معمولاً در یک بسته RPC. در زمان عملیات نوشتن، هسته بلافاصله کنترل را به فرآیند برمی‌گرداند و توابع ارسال درخواست RPC به biod منتقل می‌شوند. اگر دیمون‌های biod اجرا نمی‌شوند و هسته از پردازش RPC چند رشته‌ای پشتیبانی نمی‌کند، هسته باید بسته‌های RPC را در حالت تک رشته‌ای ارسال کند و فرآیند کاربر وارد حالت انتظار برای پایان انتقال می‌شود. اما در این مورد، کش NFS همچنان استفاده می شود.

    علاوه بر محتویات فایل‌ها و دایرکتوری‌های NFS، ویژگی‌های فایل و دایرکتوری در سمت سرویس گیرنده ذخیره می‌شوند و کش ویژگی به صورت دوره‌ای (معمولاً هر چند ثانیه یک‌بار) به‌روزرسانی می‌شود. این به این دلیل است که ارزش ویژگی ها را می توان برای قضاوت در مورد وضعیت یک فایل یا فهرست استفاده کرد. اجازه دهید این رویکرد را با یک مثال توضیح دهیم. زمانی که کاربر یک عملیات خواندن را از یک فایل انجام می دهد، محتویات فایل در حافظه پنهان NFS قرار می گیرد، اما در همان زمان، ویژگی های فایل (زمان ایجاد/به روز رسانی، اندازه و غیره) در کش ویژگی قرار می گیرد. اگر در این لحظه کلاینت دیگری در حال نوشتن روی همان فایل باشد، این امر می تواند منجر به ناهماهنگی محتوا در حافظه پنهان مشتریان مختلف شود. با این حال، از آنجایی که کش ویژگی هر چند ثانیه در اولین کلاینت به روز می شود، می تواند تشخیص دهد که ویژگی ها تغییر کرده اند (در این مورد، زمان به روز رسانی فایل)، بنابراین مشتری باید عملیات به روز رسانی کش محتوای فایل را انجام دهد (این عملیات به صورت خودکار انجام می شود).

    دیمون های nfsd باید روی سرور در حال اجرا باشند تا به درخواست های مشتری سرویس دهند. در همان زمان، دیمون ها اطلاعات را هنگام خواندن از دیسک های سرور ذخیره می کنند. همه دیمون ها صف یکسانی از درخواست های مشتری را ارائه می دهند که امکان استفاده بهینه از منابع پردازنده را فراهم می کند.

    متاسفانه تعیین تعداد بهینه دیمون های biod و nfsd بسیار مشکل است. از یک طرف، هر چه تعداد دیمون های در حال اجرا بیشتر باشد، تعداد درخواست هایی که می توانند به طور همزمان پردازش شوند بیشتر می شود. از سوی دیگر، افزایش تعداد دیمون ها می تواند بر عملکرد سیستم به دلیل افزایش سربار سوئیچینگ فرآیند تأثیر منفی بگذارد. بهینه سازی NFS رویه ای بسیار خسته کننده است و نیازمند در نظر گرفتن نه تنها تعداد کلاینت ها و فرآیندهای کاربر است، بلکه به در نظر گرفتن ویژگی هایی مانند زمان تعویض متن فرآیند (به عنوان مثال ویژگی های معماری پردازنده)، اندازه RAM، بار سیستم و غیره نیاز دارد. چنین تنظیماتی به بهترین وجه به صورت آزمایشی تعیین می شوند، اگرچه در بیشتر موارد تنظیمات استاندارد کار می کنند (معمولاً 8 daemon nfsd، daemons روی سرور biod اجرا می شوند).

    شکل 2. عملیات نوشتن NFS v2.

    یک ویژگی بسیار مهم NFS v2 این است که عملیات نوشتن در سمت سرور ذخیره نمی شود (شکل 2 را ببینید). این کار به منظور اطمینان از قابلیت اطمینان بالای سرویس NFS و اطمینان از یکپارچگی داده ها پس از راه اندازی مجدد سرور در صورت خرابی سرور انجام شد. فقدان حافظه پنهان نوشتن بزرگترین است مشکل NFS v2. در عملیات نوشتن، NFS به طور قابل توجهی نسبت به فناوری‌های رقیب پایین‌تر است، اگرچه در عملیات خواندن ضرر کمی به آن‌ها می‌دهد. تنها راه مقابله با عملکرد ضعیف نوشتن، استفاده از زیرسیستم‌های دیسک با حافظه پنهان داخلی مستقل از قدرت، مانند آرایه‌های RAID نسبتاً گران‌قیمت است.

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

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

    وضعیت تأخیر در پردازش درخواست های RPC به دلیل، مثلاً، بارگذاری زیاد سرور یا مشکلات شبکه نیز بسیار ناخوشایند است. در صورت تجاوز از محدودیت زمانی مشخص شده، مشتری در نظر می گیرد که بسته گم شده است و سعی می کند درخواست را تکرار کند. برای بسیاری از عملیات NFS، این مشکلی نیست، زیرا حتی عملیات نوشتن می تواند توسط سرور تکرار شود. اما در مورد عملیاتی مانند "حذف دایرکتوری" یا "تغییر نام فایل" چطور؟ خوشبختانه، اکثر پیاده سازی های NFS از کش کردن درخواست های تکراری در سمت سرور پشتیبانی می کنند. اگر سرور یک درخواست مکرر برای هر عملیاتی را در مدت زمان کوتاهی دریافت کند، چنین درخواستی نادیده گرفته می شود.

    سیستم RPC وضعیت اتصال را ردیابی نمی کند، که وقتی چندین مشتری به یک فایل به طور همزمان دسترسی دارند، مشکلاتی را ایجاد می کند. در اینجا دو مشکل وجود دارد:

    • چگونه یک فایل را قفل کنیم، به ویژه هنگام نوشتن در آن؛
    • چگونه می توان یکپارچگی قفل ها را در صورت خرابی و راه اندازی مجدد سرور یا کلاینت NFS تضمین کرد؟

    برای انجام این کار، NFS از دو دیمون ویژه استفاده می کند: rpc.lockd مسئول قفل کردن فایل ها است و rpc.statd مسئول نظارت بر وضعیت قفل ها است (شکل 3 را ببینید). این دیمون ها هم در سمت مشتری و هم در سمت سرور اجرا می شوند. دیمون های rpc.lockd و rpc.statd دارای دو دایرکتوری خاص (sm و sm.bak) هستند که اطلاعات قفل در آنها ذخیره می شود.

    یک سرویس اضافی عجیب و غریب و نسبتاً راحت به شما امکان می‌دهد سیستم‌های فایل را هنگامی که پردازش‌های کاربر به آن‌ها دسترسی پیدا می‌کنند، به صورت خودکار نصب کنید. در آینده، automounter به صورت دوره ای (به طور پیش فرض هر پنج دقیقه یک بار) سعی می کند سیستم را از حالت نصب خارج کند. اگر مشغول باشد (مثلاً یک فایل باز است)، سرویس طبق معمول به کار خود ادامه می دهد. اگر دسترسی دیگری به سیستم فایل وجود نداشته باشد، به طور خودکار از حالت نصب خارج می شود. عملکرد automounter چندین برنامه را پیاده سازی می کند که amd و autofs از محبوبیت خاصی برخوردار هستند.

    ویژگی های NFS V3

    NFS نسخه 3 کاملاً با نسخه 2 سازگار است، یعنی سرور NFS v3 هر دو سرویس گیرنده NFS v2 و NFS v3 را "درک" می کند. به طور مشابه، یک کلاینت NFS v3 می تواند به سرور NFS v2 دسترسی داشته باشد.

    یک نوآوری مهم در NFS v3 پشتیبانی از پروتکل انتقال TCP است. UDP برای شبکه های محلی عالی است، اما نه برای لینک های جهانی کند و نه همیشه قابل اعتماد. در NFS v3، تمام ترافیک کلاینت بر روی یک اتصال TCP مالتی پلکس می شود.

    در NFS نسخه 3، اندازه بافر کش به 64 کیلوبایت افزایش یافته است که تأثیر مفیدی بر عملکرد دارد، به ویژه با توجه به استفاده فعال از فناوری های شبکه پرسرعت Fast Ethernet، Gigabit Ethernet و ATM. علاوه بر این، NFS v3 به شما این امکان را می دهد که اطلاعات کش شده روی کلاینت را نه تنها در RAM، بلکه در دیسک محلی مشتری نیز ذخیره کنید (انصافاً باید توجه داشت که برخی از پیاده سازی های NFS v2 نیز این امکان را فراهم می کنند). این فناوری با نام CacheFS شناخته می شود.

    شکل 4. عملیات نوشتن NFS v3.

    اما شاید حتی مهمتر از NFS v3، افزایش شدید عملکرد نوشتن باشد. اکنون ذخیره اطلاعات در حال نوشتن در سمت سرور نیز انجام می شود، در حالی که ثبت و تأیید واقعیت نوشتن داده ها در دیسک با استفاده از یک درخواست commit ویژه انجام می شود (شکل 4 را ببینید). این فناوری را نوشتن امن ناهمزمان می نامند. پس از اینکه داده ها به حافظه پنهان سرور منتقل شدند، کلاینت یک درخواست commit برای آن ارسال می کند که عملیات نوشتن را روی دیسک سرور آغاز می کند. به نوبه خود، هنگامی که اطلاعات بر روی دیسک نوشته می شود، سرور تاییدیه تکمیل موفقیت آمیز آن را برای مشتری ارسال می کند.

    جدید در NFS v3 پشتیبانی از سیستم های فایل 64 بیتی و پشتیبانی بهبود یافته از ACL ها است.

    با نگاهی به آینده، Sun در حال حاضر فناوری WebNFS را ترویج می‌کند که امکان دسترسی به سیستم‌های فایل را از هر کجا فراهم می‌کند. مرورگر اینترنتیا از طریق برنامه های نوشته شده در جاوا. نیازی به نصب نرم افزار مشتری نیست. WebNFS (به گفته Sun) سه تا پنج برابر بهبود عملکرد نسبت به ftp یا HTTP است.

    نتیجه

    با دانستن اصول پروتکل های NFS، مدیر می تواند بهترین تنظیمات را برای سرویس انجام دهد. سیستم فایل شبکه NFS برای شبکه های یونیکس ایده آل است، زیرا تقریباً با تمام نسخه های این سیستم عامل ارائه می شود. علاوه بر این، پشتیبانی NFS در سطح هسته یونیکس پیاده سازی می شود. از آنجایی که لینوکس به آرامی در سطح دسکتاپ به دست می‌آورد، NFS این فرصت را دارد که در اینجا نیز پیشرفت کند. متأسفانه، استفاده از NFS در رایانه های سرویس گیرنده ویندوز، مشکلات خاصی را در ارتباط با نیاز به نصب نرم افزار مشتری تخصصی و نسبتاً گران قیمت ایجاد می کند. در چنین شبکه هایی، استفاده از سرویس SMB، به ویژه نرم افزار سامبا، ارجح تر به نظر می رسد. با این حال، در یکی از شماره های بعدی LAN به محصولات SMB برای یونیکس باز خواهیم گشت.

    بیشتر بخوانید: