Протокол мережної файлової служби (Network File Server, NFS) – це відкритий стандарт на надання користувачеві віддаленого доступу до файлових систем. Створені на його основі централізовані файлові системи полегшують щоденне виконання таких завдань як резервне копіювання або перевірка на віруси, а об'єднані дискові розділи простіше обслуговувати, ніж безліч невеликих і розподілених.
Крім того, що система NFS надає можливість централізованого зберігання, вона виявилася дуже корисною і для інших додатків, включаючи роботу з бездисковими та тонкими клієнтами, розбиття мережі на кластери, а також для спільно працюючого міжплатформного програмного забезпечення.
Найкраще розуміння як самого протоколу, так і деталей його реалізації дозволить легше впоратися із практичними завданнями. Ця стаття присвячена NFS і складається з двох логічних частин: спочатку описується сам протокол та цілі, поставлені при його розробці, а потім реалізації NFS у Solaris та UNIX.
З ЧОГО ВСЕ ПОЧИНАЛОСЯ...
Протокол NFS розроблений компанією Sun Microsystems й у 1989 р. з'явився у Internet як документа RFC 1094 під такою назвою: «Специфікація протоколу мережевої файлової системи» (Network File System Protocol Specification, NFS). Цікаво відзначити, що і стратегія компанії Novell на той час була спрямована на подальше вдосконалення файлових служб. Донедавна, поки рух за відкриті коди ще не набрало чинності, Sun не прагнула розкривати секрети своїх мережевих рішень, проте навіть тоді в компанії розуміли всю важливість забезпечення взаємодії з іншими системами.
У документі RFC 1094 містилися дві первісні специфікації. На момент його публікації Sun розробляла вже наступну, третю версію специфікації, яка викладена в RFC 1813 "Специфікація протоколу NFS, версія 3" (NFS Version 3 Protocol Specification). Версія 4 цього протоколу визначена в RFC 3010 "Специфікація протоколу NFS, версія 4" (NFS Version 4 Protocol).
NFS широко використовується на всіх типах вузлів UNIX, мережах Microsoft і Novell, а також у таких рішеннях компанії IBM, як AS400 і OS/390. Будучи невідомою за межами мережевого «королівства», NFS, мабуть, найпоширеніша платформно-незалежна мережна файлова система.
ПРАЦЕМ БУВ UNIX
Хоча NFS - платформно-незалежна система, її прабатьком є UNIX. Іншими словами, ієрархічність архітектури та методи доступу до файлів, включаючи структуру файлової системи, способи ідентифікації користувачів та груп та прийоми роботи з файлами – все це дуже нагадує файлову систему UNIX. Наприклад, файлова система NFS, будучи за структурою ідентичної файлової системи UNIX, монтується у ній. При роботі з NFS на інших операційних системах ідентифікаційні параметри користувачів та права доступу до файлів зазнають перетворення (mapping).
NFS
Система NFS призначена для застосування у клієнт-серверній архітектурі. Клієнт отримує доступ до файлової системи, яка експортується сервером NFS, за допомогою точки монтування на клієнті. Такий доступ зазвичай прозорий для клієнтської програми.
На відміну від багатьох клієнт-серверних систем, NFS для обміну інформацією використовує виклики віддалених процедур (Remote Procedure Calls, RPC). Зазвичай клієнт встановлює з'єднання із заздалегідь відомим портом і потім, відповідно до особливостей протоколу, надсилає запит на виконання певної дії. У разі виклику віддалених процедур клієнт створює виклик процедури та відправляє його на виконання серверу. Детальний опис NFS буде наведено нижче.
Як приклад припустимо, що клієнт змонтував каталог usr2 в локальної кореневої файлової системі:
/root/usr2/ -> remote:/root/usr/
Якщо клієнтському додатку необхідні ресурси цього каталогу, він просто надсилає запит операційній системі на нього та на ім'я файлу, а той надає доступ через клієнта NFS. Наприклад розглянемо просту команду UNIX cd, яка «нічого не знає» про мережеві протоколи. Команда
Cd /root/usr2/
розмістить робочий каталог на віддаленій файловій системі, "навіть не здогадуючись" (користувачу теж немає в цьому необхідності), що файлова система є віддаленою.
Отримавши запит, сервер NFS перевірить наявність у даного користувача права на виконання дії, що запитується, і в разі позитивної відповіді здійснить його.
ПОЗНАЙОМИМОСЯ БЛИЖЧЕ
З погляду клієнта, процес локального монтування віддаленої файлової системи засобами NFS складається з кількох кроків. Як згадувалося, клієнт NFS подасть виклик віддаленої процедури виконання її на сервері. Зауважимо, що в UNIX клієнт є однією програмою (команда mount), тоді як сервер насправді реалізований у вигляді кількох програм з наступним мінімальним набором: служба перетворення портів (port mapper), демон монтування (mount daemon) і сервер NFS .
Спочатку клієнтська команда mount взаємодіє зі службою перетворення портів сервера, що очікує запити через порт 111. Більшість реалізацій клієнтської команди mount підтримує кілька версій NFS, що підвищує можливість знаходження спільної для клієнта та сервера версії протоколу. Пошук ведеться, починаючи з найстаршої версії, тому коли загальна буде знайдена, вона автоматично стане і найновішою версією з підтримуваних клієнтом і сервером.
(Викладений матеріал орієнтований на третю версію NFS, оскільки вона найпоширеніша на даний момент. Четверта версія більшістю реалізацій поки що не підтримується.)
Служба перетворення портів сервера відгукується на запити відповідно до протоколу та порту, на якому працює демон монтування. Клієнтська програма mount спочатку встановлює з'єднання з демоном монтування сервера, потім передає йому за допомогою RPC команду mount. Якщо дана процедура виконана успішно, то клієнтська програма з'єднується з сервером NFS (порт 2049) і, використовуючи одну з 20 віддалених процедур, визначених у RFC 1813 і наведених нами в Таблиці 1, отримує доступ до віддаленої файлової системи.
Сенс більшості команд інтуїтивно зрозумілий і не викликає жодних труднощів у системних адміністраторів. Нижче наведений листинг, отриманий за допомогою tcdump, ілюструє команду читання, створювану командою UNIX cat для прочитання файлу з ім'ям test-file:
10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 lookup fh 32,0/ 224145 "test-file" 10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 lookup fh 32,0/ 224145 "test-file" 10:30:16.012729 eth0 192.168.1.254.34 /224307 (DF) 10:30: 16.012729 eth0 192.168.1.254.3476097947: reply ok 128 lookup fh 32,0/224307 (DF) 10:30:16.013124 eth0 > 192.168. 3492875163 > 192.168.1.252.2049: 140 read fh 32,0/ 224307 4096 bytes @ 0 10:30:16.013124 eth0 > 192.168.1.25 3492875163 > 192.168.1.252.2049: 140 read fh 32,0/ 224307 4096 bytes @ 0 10:30:16.013650 eth0 192.168.1.28 . 0:30:16.013650 eth0 192.168.1.254.3492875163 : reply ok 108 read (DF)
NFS традиційно реалізується з урахуванням UDP. Однак деякі версії NFS підтримують TCP (у специфікації протоколу визначено підтримку TCP). Головна перевага TCP - ефективніший механізм повторної передачі у ненадійно працюючих мережах. (У разі UDP, якщо сталася помилка, повне повідомлення RPC, що складається з декількох пакетів UDP, пересилається заново. За наявності TCP заново пересилається лише зіпсований фрагмент.)
ДОСТУП У NFS
У реалізаціях NFS зазвичай підтримуються чотири способи надання прав доступу: за допомогою атрибутів користувача/файлу, на рівні ресурсів, що розділяються, на рівні головного вузла, а також у вигляді комбінації інших методів доступу.
Перший спосіб ґрунтується на вбудованій UNIX системі прав доступу до файлів для індивідуального користувача або групи. Для спрощення обслуговування ідентифікація користувачів та груп має бути однаковою для всіх клієнтів та серверів NFS. Захист слід ретельно продумати: в NFS можна необережно надати такий доступ до файлів, який не планувався при їх створенні.
Доступ на рівні ресурсів, що розділяються, дозволяє обмежувати права, дозволивши лише певні дії, незалежно від приналежності файлу або привілеїв UNIX. Наприклад, роботу з файловою системою NFS можна обмежити лише читанням. Більшість реалізацій NFS дозволяє додатково обмежити доступ на рівні ресурсів, що розділяються конкретними користувачами та/або групами. Наприклад, групі "Відділ кадрів" дозволяється перегляд інформації і не більше.
Доступ на рівні головного вузла дозволяє монтувати файлову систему тільки на конкретних вузлах, що, взагалі кажучи, гарна ідея, оскільки файлові системи можуть легко створюватись на будь-яких вузлах, які підтримують NFS.
Комбінований доступ просто поєднує вищеописані види (наприклад, доступ на рівні ресурсів, що розділяються з доступом, що надається конкретному користувачеві) або дозволяє користувачам роботу з NFS тільки з певного вузла.
NFS У СТИЛІ «ПІНГВІН»
Матеріал, що стосується Linux, базується на системі Red Hat 6.2 з ядром версії 2.4.9, яка поставляється з пакетом nfs-utils версії 0.1.6. Існують і новіші версії: на момент написання цієї статті останнє оновлення пакета nfs-utils мало номер 0.3.1. Його можна завантажити на адресу: .
Пакет nfs-utils містить наступні файли, що виконуються: exportfs, lockd, mountd, nfsd, nfsstat, nhfsstone, rquotad, showmount і statd.
На жаль, іноді підтримка NFS викликає плутанину у адміністраторів Linux, оскільки наявність тієї чи іншої функціональної можливості залежить від номерів версій як ядра, так і пакета nfs-utils. На щастя, в даний час стан справ у цій галузі покращується: останні дистрибутивні комплекти включають нові версії і того, і іншого. Для попередніх випусків у розділі 2.4 документа NFS-HOWTO наводиться повний список функціональних можливостей системи, наявних для кожної комбінації ядра та пакету nfs-utils. Розробники підтримують зворотну сумісність пакета з попередніми версіями, приділяючи багато уваги забезпеченню безпеки та усунення програмних помилок.
Підтримка NFS слід ініціювати під час компіляції ядра. Якщо необхідно, до ядра потрібно додати і можливість роботи з NFS версії 3.
Для дистрибутивів, що підтримують linuxconf, легко налаштувати служби NFS як для клієнтів, так і для серверів. Однак швидкий спосіб встановлення NFS за допомогою linuxconf не дає інформації про те, які файли були створені або редаговані, що дуже важливо знати адміністратору для розуміння ситуації у разі збою системи. Архітектура NFS в Linux має слабкий зв'язок з версією BSD, тому необхідні файли та програми підтримки легко знайти адміністраторам, які працюють з BSD, Sun OS 2.5 або більш ранніми версіями NFS.
Файл /etc/exports, як і в попередніх версіях BSD, визначає файлові системи, до яких дозволено доступ клієнтам NFS. Крім того, він містить низку додаткових можливостей, що стосуються питань управління та безпеки, надаючи адміністратору засіб для тонкого налаштування. Це текстовий файл, що складається із записів, порожніх або закоментованих рядків (коментарі починаються із символу #).
Припустимо, що ми хочемо надати клієнтам доступ тільки для читання каталогу /home на вузлі Lefty. Цьому /etc/exports відповідатиме наступний запис:
/home (ro)
Тут нам необхідно повідомити систему, які каталоги ми збираємось зробити доступними за допомогою демона монтування 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, secure_locks, mapping=identity,anonuid=-2,anongid=-2)
Інші параметри, перелічені у вигляді списку в etab, включають стандартні значення, що використовуються NFS. Деталі будуть описані нижче. Щоб надати доступ до каталогу /home, необхідно запустити відповідні служби NFS:
# portmap # rpc.mountd # rpc.nfsd # rpc.statd # rpc.rquotad
У будь-який момент після запуску демона монтування (rpc.mountd) можна дізнатися про окремі файли, доступні для виведення, можна, переглянувши вміст файлу /proc/fs/nfs/exports:
# cat /proc/fs/nfs/exports # Version 1.0 # Path Client(Flags) # IPs /home 192.168.1.252(ro,root_squash,async, wdelay) # 192.168.1.252 #
Те саме можна переглянути і за допомогою команди showmount з параметром -e:
# showmount -e Export list for lefty: /home (everyone) #
Забігаючи кілька вперед, скажу, що команду showmount можна використовувати для визначення всіх змонтованих файлових систем, або, іншими словами, щоб з'ясувати, які вузли є клієнтами NFS для системи, на якій запущена команда showmount. Команда showmount -a виведе всі клієнтські точки монтування:
# showmount -a All mount points on lefty: 192.168.1.252:/home #
Як зазначалося вище, більшість реалізацій NFS підтримує різні версії цього протоколу. Реалізація в Linux дозволяє обмежувати список версій NFS, що запускаються, шляхом вказівки ключа -N для демона монтування. Наприклад, для запуску третьої версії NFS, і тільки її, введіть наступну команду:
# rpc.mountd -N 1 -N 2
Вибагливим користувачам може здатися незручним, що в Linux демон NFS (rpc.nfsd) знаходиться в режимі очікування пакетів версій 1 і 2, хоча це досягає бажаного ефекту відмови від підтримки відповідного протоколу. Сподіватимемося, що розробники наступних версій внесуть необхідні виправлення і зможуть домогтися більшої узгодженості компонентів пакета щодо різних версій протоколу.
«ЗАПЛИВ З ПІНГВІНАМИ»
Доступ до конфігурованої вище Lefty, що експортується файловою системою NFS на базі Linux, залежить від клієнтської операційної системи. Стиль установок для більшості операційних систем сімейства UNIX збігається зі стилем або вихідних систем Sun OS і BSD, або новішої Solaris. Так як ця стаття присвячена обом системам, Linux і Solaris, розглянемо клієнтську конфігурацію Solaris 2.6 з точки зору встановлення з'єднання з Linux-версією NFS, описаної нами вище.
Завдяки властивостям, успадкованим Solaris 2.6, її легко налаштувати для роботи клієнтом NFS. Для цього потрібна лише одна команда:
# mount -F nfs 192.168.1.254:/home /tmp/tmp2
Припустимо, що попередня команда mount виконана успішно, тоді команда mount без параметрів виведе наступне:
# mount / on /dev/dsk/c0t0d0s0 read/write/setuid/ largefiles on Mon Sep 3 10:17:56 2001 ... ... /tmp/tmp2 on 192.168.1.254:/home read/ write/remote on Mon Sep 3 23:19:25 2001
Давайте проаналізуємо висновок 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 Unknown/1 (DF) 06:07:n. 2191983953: reply ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:07:43.491397 sunny.2191983954 > lefty.mcwn 06:07:43.491463 lefty. mcwrite.n.nfs > sunny.2191983954: reply ok 120 access c0001 (DF) 06:07:43.492296 sunny.2191983955 > lefty.mcwrite.n.nfs, 182 7 @ 0x000000000 (DF) 06:07:43.492417 lefty.mcwrite.n.nfs > sunny.2191983955: reply ok 1000 readdirplus (DF)
Ми бачимо, що вузол Sunny запитує ls описувач файлу (fh), на що вузол Lefty у відповідь посилає OK і повертає структуру каталогу. Потім Sunny перевіряє дозвіл на право доступу до вмісту каталогу (132 access fh) і отримує відповідь з дозволом Lefty. Після цього вузол Sunny, використовуючи процедуру readdirplus, зчитує повний вміст каталогу. Виклики віддалених процедур описані в документі RFC 1813 та наведені нами на початку цієї статті.
Хоча послідовність команд для доступу до віддалених файлових систем дуже проста, низка обставин може призвести до некоректного монтування системи. Перед монтуванням каталогу точка монтування має вже існувати, інакше її необхідно створити за допомогою команди mkdir. Зазвичай єдиною причиною помилок на стороні клієнта є відсутність локального каталогу для монтування. Більшість проблем, пов'язаних з NFS, зобов'язані своїм походженням невідповідності між клієнтом і сервером або некоректної конфігурації сервера.
Найпростіше усунути проблеми на сервері з вузла, на якому працює сервер. Однак, коли адміністрування сервера займається замість вас хтось інший, це не завжди можливо. Швидкий спосіб переконатися, що відповідні служби сервера правильно налаштовані - використовувати команду rpcinfo з параметром -p. З вузла Solaris Sunny можна визначити, які процеси RPC зареєстровані на вузлі Linux:
# rpcinfo -p 192.168.1.254 program vers proto port service 100000 2 tcp 111 rpcbind 100000 2 udp 111 rpcbind 100024 1 udp 692 status 100000 1024 mountd /100005 3 tcp 1024 mountd 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100021 1 udp 1026 nlockmgr 100021 3 udp 1026 nlockmgr 100021 4 udp 1026 nlockmgr #
Зауважимо, що тут наводиться інформація про версії, що досить корисно, коли для роботи системи потрібна підтримка різних протоколів NFS. Якщо будь-яка служба не запущена на сервері, така ситуація має бути виправлена. У разі невдалого монтування команда rpcinfo -p дозволить з'ясувати, що служба mountd на сервері не працює:
# rpcinfo -p 192.168.1.254 program vers proto port service 100000 2 tcp 111 rpcbind ... ... 100021 4 udp 1026 nlockmgr #
Команда rpcinfo дуже корисна для з'ясування, чи активний той чи інший віддалений процес. Параметр -p - найважливіший із ключів. Для ознайомлення з усіма можливостями rpcinfo зверніться до довідкової сторінки man.
Інший корисний засіб – команда nfsstat. З її допомогою можна дізнатися, чи звертаються клієнти до експортованої файлової системи, а також вивести статистичну інформацію відповідно до версії протоколу.
Зрештою, ще одним досить корисним інструментом визначення причин збоїв системи є tcpdump:
# tcpdump host lefty і host sunny -s512 tcpdump: listening on eth0 06:29:51.773646 sunny.2191984020 > lefty.mcwrite.n.nfs: 140 lookup fh Unkn1:1 lefty.mcwrite.n.nfs > sunny.2191984020: reply ok 116 lookup ERROR: Немає такого файлу або directory (DF) 06:29:51.774593 sunny.2191984021 > lefty.mchrite DF) 06:29:51.774670 lefty.mcwrite.n.nfs > sunny.2191984021: reply ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF528) 06 > lefty.mcwrite.n.nfs : 140 lookup fh Unknown/1"test.c" (DF) 06:29:51.775357 lefty.mcwrite.n.nfs > sunny.2191984022: reply ok 116 lookup EDF: 51.776029 sunny.2191984023 > lefty.mcwrite.n.nfs: 184 create fh Unknown/1 "вихід. : Permission denied (DF)
Наведений вище листинг, отриманий після виконання інструкції touch test.c, відображає наступну послідовність дій: спочатку команда touch намагається отримати доступ до файлу на ім'я test.c, потім вона шукає каталог з цим же ім'ям, а після невдалих спроб намагається створити файл test.c що також не призводить до успіху.
Якщо файлова система змонтована, більшість типових помилок пов'язані з звичайними правами доступу UNIX. Використання uid або NIS+ у Sun допомагає уникнути глобального встановлення прав доступу на всі файлові системи. Деякі адміністратори практикують «відкриті» каталоги, коли права доступу на їх читання надаються «усьому світу». Однак цього слід уникати причин безпеки. Навіть відкинувши у бік проблеми захисту, все одно доведеться визнати такий підхід хибною практикою, оскільки користувачі рідко створюють дані з наміром зробити їх доступними для читання всім поспіль.
Звертання привілейованого користувача (root) до змонтованих файлових систем NFS трактуються по-особливому. Щоб уникнути надання привілейованому користувачеві необмеженого доступу, запити від нього трактуються так, ніби вони надходять від користувача nobody («ніхто»). Цей ефективний механізм обмежує доступ привілейованого користувача глобально доступними для читання та дозволеними для запису файлами.
СЕРВЕР NFS, ВЕРСІЯ SOLARIS
Конфігурування Solaris для роботи як сервер NFS так само просто, як і у випадку з Linux. Однак команди та розташування файлів дещо відрізняються. Під час початкового завантаження Solaris після досягнення рівня завантаження 3 (run level 3) автоматично запускаються служби NFS та експортуються всі файлові системи. Для запуску цих процесів уручну введіть команду:
#/usr/lib/nfs/mountd
Щоб запустити демон монтування та сервер NFS, введіть:
#/usr/lib/nfs/nfsd
Починаючи з версії 2.6 у Solaris для вказівки файлових систем, що експортуються, більше не використовується файл експорту. Тепер файли експортуються за допомогою команди share. Припустимо, ми хочемо дозволити дистанційним вузлам змонтувати /export/home. Введемо для цього наступну команду:
Share -F nfs /export/home
Заходи щодо забезпечення безпеки
БЕЗПЕКА В LINUX
Деякі системні служби NFS на основі Linux мають додатковий механізм обмеження доступу за допомогою керуючих списків або таблиць. На внутрішньому рівні цей механізм реалізований за допомогою бібліотеки tcp_wrapper, яка для формування списків контролю доступу використовує два файли: /etc/hosts.allow та /etc/hosts/deny. Вичерпний огляд правил роботи з tcp_wrapper виходить за рамки цієї статті, основний принцип полягає в наступному: зіставлення спочатку проводиться з etc/hosts.allow, а потім з /etc/hosts. deny. Якщо правило не знайдено, то запитувана системна служба не представляється. Щоб оминути останню вимогу і забезпечити дуже високий рівень безпеки, можна додати наступний запис: /etc/hosts.deny:
ALL: All
Після цього можна використовувати /etc/ hosts.allow, щоб встановити той чи інший режим роботи. Наприклад файл /etc/hosts. allow, який я використовував при написанні цієї статті, містив такі рядки:
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:52.5. 92.168.1.0/255.255.255.0
При цьому дозволяється певний вид доступу до вузлів до надання доступу на рівні додатків. У Linux доступом на рівні програм керує файл /etc/exports. Він складається із записів у наступному форматі:
Експортований каталог (пробіл) вузол | мережа (опції)
«Експортований каталог» - це каталог, обробка запиту якого дозволена демону nfsd. "Вузол|мережа" - це вузол або мережа, що мають доступ до файлової системи, що експортується, а "опції" визначають ті обмеження, які демон nfsd накладає на використання даного розділюваного ресурсу, - доступ тільки для читання або перетворення ідентифікатора користувача (user id mapping) .
У наступному прикладі всьому домену mcwrite.net надано доступ у режимі тільки для читання /home/mcwrite.net:
/home/mcwrite.net *.mcwrite.net(ro)
Інші приклади можна знайти на довідковій сторінці exports man.
БЕЗПЕКА NFS У SOLARIS
У Solaris можливості надання доступу до NFS аналогічні Linux, проте в цьому випадку обмеження задаються за допомогою певних параметрів у команді share з ключем -o. Наступний приклад показує, як дозволити монтування в режимі лише для читання /export/mcwrite.net на будь-якому вузлі домену mcwrite.net:
#share -F nfs -o ro=.mcwrite.net/export/mcwrite.net
Довідкова сторінка man для share_nfs докладно описує надання доступу за допомогою керуючих списків Solaris.
Ресурси Internet
У NFS і RPC не обійшлося без "дір". Взагалі, NFS не слід використовувати при роботі в Internet. Не можна робити «дірки» в брандмауерах, надаючи будь-який доступ через NFS. Необхідно ретельно стежити за всіма латами, що з'являються, для RPC і NFS, в чому можуть допомогти численні джерела інформації з питань безпеки. Два найбільш популярні джерела - Bugtraq і CERT:
Перший можна регулярно переглядати у пошуках необхідної інформації або скористатися підпискою на періодичну розсилку новин. Другий надає, можливо, не таку оперативну, в порівнянні з іншими, інформацію, зате в досить повному обсязі і без відтінку сенсаційності, властивої деяким сайтам, присвяченим інформаційній безпеці.
Для роздачі файлів усередині локальної мережі можна виділити такі технології (розглядаються системи на базі Linux):
- Network File System (NFS) – протокол мережного доступу до файлових систем;
- Files transferred over Shell protocol (FISH) - мережевий протокол, який використовує або RSHпередачі файлів між комп'ютерами;
- Secure SHell FileSystem (SSHFS) – клієнт файлової системи для монтування дискових пристроїв на віддалених системах, для взаємодії з віддаленою системою використовується SFTP;
- Samba - пакет програм, які дозволяють звертатися до мережних дисків та принтерів на різних операційних системах за протоколом SMB/CIFS;
У цій статті мова піде про NFS.
NFS (Network File System)корисна, коли потрібно роздати файли/директорії всім усередині мережі. Прозорість доступу за допомогою NFSдозволяє клієнтам підключити віддалену файлову систему як локальну директорію, причому файлові системи можуть бути різних типів. Це означає, що будь-яка програма клієнта, яка може працювати з локальним файлом, з таким же успіхом може працювати і з файлом підключеним по NFSбез будь-яких модифікацій самої програми.
До переваг NFSможна віднести:
На даний момент доступна NFS v4.1, в якій запровадили нову можливість pNFSщо дозволяє розпаралелити реалізацію загального доступу до файлів. Також є розширення для NFS 2 та 3 - WebNFS, яка дозволяє легше інтегруватися в веб-браузери і дає можливість працювати через брандмауер.
Схема роботи NFSпротоколу.
Встановлення та налаштування NFS-сервер під Linux
Перевіримо, чи підтримує система NFS
Cat /proc/filesystems | grep nfs
Під Arch Linuxсервер та клієнт перебувати в одному пакеті
Yaourt -S nfs-utils
Для встановлення сервера ( nfs-kernel-server) та клієнта ( nfs-common) під Ubuntuнеобхідні пакети
Sudo apt-get install nfs-kernel-server nfs-common portmap
Далі в замітці для сервера використовуватиметься IP 192.168.1.100 . Для того щоб за сервером завжди був закріплений один і той же IP необхідно в DHCP-сервері (найчастіше роутер) вказати роздачу конкретної IP конкретної MAC-адреси. Або підняти свій локальний DNS-сервер. Наприклад, або .
MAC-адресу можна дізнатися за допомогою ifconfig (поле etherв Arch Linux).
NFSv4припускає, що є коренева директорія, всередині якої вже розташовані файли для роздачі. Наприклад, /srv/nfs- корінь, /srv/nfs/audio- Директорія для роздачі музики. Якщо не дотримуватися цієї нової вказівки у версії 4 , то можна отримати помилку при підключенні клієнтом:
Mount.nfs: access denied by server while mounting 192.168.1.100:/home/proft/torrents
Якщо все ж таки хочеться використовувати на сервері підхід без кореневої-директорії для NFS, то при монтуванні клієнтом треба явно вказати версію 3
# для команди mount mount -o "vers=3" 192.168.1.100:/home/proft/torrents /home/proft/nfs/torrents # для fstab 192.168.1.100:/home/proft/torrents /home/proft/nfs/ torrents nfs soft,nfsvers=3 0 0
Я буду використовувати NFSv4з root-директорією в /srv/nfs/та монтуванням вкладених директорій за допомогою mount --bind .
Припустимо, що ми хочемо
- роздавати директорію ~/torrentsз rwдоступом для всіхусередині локальної мережі;
- роздавати директорію ~/photosз roдоступом для хоста з IP 192.168.1.101 ;
Для початку створимо кореневу директорію та необхідні вкладені.
Sudo mkdir -p /srv/nfs/(torrents,photos)
Примонтуємо існуючі директорії torrents, photosв /srv/nfs.
# sudo vim /etc/fstab /home/proft/torrents /srv/nfs/torrents none bind 0 0 /home/proft/photos /srv/nfs/photos none bind 0 0
Відредагуємо /etc/exports, в якому описуються всі директорії для спільного доступу
# sudo vim /etc/exports # формат файлу: directory allowed-hosts(options) /srv/nfs/torrents 192.168.1.1/24(rw,async) /srv/nfs/photos 192.168.1.101(ro,async)
Зверніть увагу на відсутність пробілу між allowed-hostsі (options). Наявність пропуску вводить інше трактування правил.
Доступні опції:
- ro (rw) - дозволити доступ лише читання (читання/запис);
- subtree_check (no_subtree_check) - у деяких випадках доводиться експортувати не весь розділ, лише його частина. При цьому сервер NFSповинен виконувати додаткову перевірку звернень клієнтів, щоб переконатися, що вони роблять спробу доступу лише до файлів, які у відповідних подкаталогах. Такий контроль піддерева ( subtree checks) Дещо уповільнює взаємодію з клієнтами, але якщо відмовитися від нього, можуть виникнути проблеми з безпекою системи. Скасувати контроль піддерева можна за допомогою опції no_subtree_check. Опція subtree_check, Що включає такий контроль, передбачається за умовчанням. Контроль піддерева можна не виконувати в тому випадку, якщо каталог, що експортується, збігається з розділом диска;
- sync (async) – вказує, що сервер повинен відповідати на запити лише після запису на диск змін, виконаних цими запитами. Опція asyncпоказує серверу чекати запису інформації на диск, що підвищує продуктивність, але знижує надійність, т.к. у разі обриву з'єднання або відмови обладнання можлива втрата даних;
- noaccess – забороняє доступ до зазначеної директорії. Може бути корисною, якщо перед цим було задано доступ всім користувачам мережі до певної директорії, і тепер хочете обмежити доступ у піддиректорії лише деяким користувачам;
- no_root_squash – за замовчуванням користувач rootна клієнтській машині не матиме тих же прав до директорії на сервері. Ця опція знімає це обмеження;
- nohide - NFSавтоматично не показує нелокальні ресурси (наприклад, примонтовані за допомогою mount --bind); ця опція включає відображення таких ресурсів;
- insecure - використання непривілейованих портів (>1024);
Запускаємо NFS-сервер
# під archlinux sudo systemctl start rpc-idmapd.service rpc-mountd.service # під ubuntu sudo /etc/init.d/nfs-kernel-server start
Надалі при зміні конфігураційного файлу достатньо його перечитати командою:
Sudo exportfs -rav
Команда rpcinfo-p | grep nfs дозволяє перевірити успішність запуску сервера.
Клієнт під Linux
Встановлення
# під archlinux yaourt -S nfs-utils # під ubuntu sudo apt-get install portmap nfs-common
Створимо директорії для монтування мережевих ресурсів torrentsі photos
Mkdir -p ~/nfs/(torrents,photos)
Для ручного монтування виконаємо
192.168.1.100:/srv/nfs/torrents /home/proft/nfs/torrents sudo mount -t nfs -o rw,soft 192.168.1.100:/srv/nf /proft/nfs/photos
Опція softвказує тихо скасувати спроби підключити кулі після певної кількості часу (час задається опцією retrans). Детальніше у man nfs.
Цей спосіб не дуже зручний, оскільки кожного разу після перезавантаження доведеться виконувати ці команди. Зробимо монтування автоматичним.
Для автоматичного монтування редагуємо файл /etc/fstab
# sudo vim /etc/fstab 192.168.1.100:/srv/nfs/torrents /home/proft/net/torrents nfs rw,soft 0 0 192.168.1.100:/srv/nfs/photos /home/proft/net/photo ro,soft 0 0
Але й цей спосіб має свої недоліки, наприклад, якщо сервер не доступний, то завантаження клієнта може підвиснути через спроби підключитися до NFS-сервера. Для виправлення цього див. AutoFS.
AutoFS - автоматичне підключення мережевих ресурсів
Є можливість монтувати віддалений ресурс за допомогою AutoFSпри першому зверненні та автоматично відмонтувати за відсутності активності.
AutoFSвикористовує для налаштування шаблони, розташовані в /etc/autofs. Основний шаблон називається auto.master, може вказувати на один або кілька інших шаблонів для конкретних типів носіїв.
Встановлення
# під archlinux yaourt -S autofs # під ubuntu sudo apt-get install autofs
Існує кілька способів зазначити способи автомонтування. Я використовую такий: /home/proft/nfsавтоматично створюється директорія з ім'ям сервера NFS, в якій автоматично створюються доступні директорії на сервері.
# sudo vim /etc/autofs/auto.master /home/proft/nfs /etc/autofs/auto.nfs --timeout=60
Додатковий параметр timeoutвстановлює кількість секунд після яких пристрій буде розмонтовано. Параметр ghostвказує що налаштовані ресурси будуть відображатися завжди, а не тільки тоді, коли вони доступні (ця опція включена за замовчуванням у AutoFS 5)
Опишемо в /etc/autofs/auto.nfs NFS-сервер та root-директорію.
# sudo vim /etc/autofs/auto.nfs nfsserver 192.168.1.100:/srv/nfs
Тепер при першому зверненні /home/proft/nfs/torrentsвідбудеться автоматичне монтування NFS-ресурсу.
Перезапустимо службу autofs:
# під archlinux sudo systemctl restart autofs # під ubuntu sudo /etc/init.d/autofs restart
Також можна вказати час очікування доступності NFS-ресурсу. Для цього необхідно змінити значення MOUNT_WAIT.
# під archlinux # sudo vim /etc/conf.d/autofs MOUNT_WAIT=5 # під ubuntu sudo /etc/default/autofs MOUNT_WAIT=5
Форсування використання NFS v3
В деяких випадках NFSv4може працювати повільно. Для виправлення цього можна вказати використовувати третю версію.
» і вже маєш уявлення про «мережеву файлову систему», її можливості та ступінь захищеності. Однак у зазначеній статті все розбиралося в основному з погляду клієнта ... а от як бути якщо тобі захотілося мати власний NFS-сервер? (прим.: «набути» не означає «зламати», а значить «встановити і налаштувати»).
Ну, а якщо бажання таке у тебе з'явилося, то перше питання, яке ти маєш поставити собі: «А нафіга козі баян?». Бо ставити NFS-сервер у себе вдома
досить безглуздо — ніхто не оцінить, а от якщо тобі пощастило адмінити в конторі «людей у чорному», або в новомодній «Домашній мережі» — тоді зовсім інша річ…
Запустити сам сервер справа досить нехитра, якщо ти читав попередню статтю, цілком з цим впораєшся. Отже, тобі знадобляться такі демони:
- nfsd - безпосереднє обслуговування протоколу
NFS; - mountd - обслуговування операцій монтування;
- rpc.portmap - демон портів RPC; потрібен оскільки запити до NFS-сервера передаються у вигляді пакетів
RPC;
Як це зробити? Дуже просто - сходи у файл "/etc/rc.d/rc.inet2" і розкоментуй відповідні рядки. Все можна вважати, що первинний запуск здійснено, трохи складніше все це налаштувати.
Перше, що треба вирішити, — це хто і які права має щодо тієї чи іншої інформації. Це налаштовується за допомогою файлу /etc/exports. Дозволи бувають «на читання» та «на читання та запис». Як це налаштовується, описано в «Основах
NFS».
Друге - це звичайно навантаження на сервер, тобто. кількість активних користувачів та їх зразкові запити. Запити до NFS-серверу зазвичай ділять на два типи: перший – коли клієнт працює з атрибутами, другий – коли клієнт запитує безпосередньо дані. Запити першого типу - це пошук файлу, зчитування списку дозволів і т.д., звичайно, ти розумієш, що вони слабо навантажують мережу. Запити другого типу - це передача та прийом від клієнта безпосередньо вмісту файлів; і саме тут постає питання: «що і як часто передаватиметься?» Цей особливо актуальний, якщо ти маєш мережу в 10 Мбіт/сек (ну простіше кажучи — стандартна російська мережа). Якщо ти знаєш, то 10 Мбіт/сек - це трохи більше 1 Мбайт на секунду; Звичайно, якщо постійно будуть передаватися файли розміром в десятки мегабайт, то мережа просто помре. Якщо твоя ситуація саме така, то тобі знадобиться встановити кешування даних на клієнтській машині (демон biod). Тоді, одного разу зажадавши якийсь файл і звернувшись до нього повторно, клієнт не «качати» його наново з сервера, а візьме у себе з кешу; при цьому регулярно перевірятиметься чи не змінився файл на сервері, якщо ж факт зміни буде виявлено, то файл у кеші буде замінений «свіжою версією»
(як ти розумієш, перевірка «змінився чи файл» — це запит «за атрибутами», який найчастіше в сотні разів менший, ніж сам файл).
Що ж: NFS-сервер ми запустили, дозволи на доступ визначили, з навантаженням розібралися… Тепер залишилося забити гвинт необхідною інфою та користуватися
можливостями NFS на повну котушку.
Замість висновку:
Якщо перед тобою стоїть питання організації обміну даними в мережі, то не роздумуючи вибирай NFS — NFS на три голови вище за голову вище, ніж
FTP і на голову вище віндових «куль», а в налаштуванні не така вже й складна.
Наводжу інструкцію з встановлення та налаштування NFS (Network File System). NFS – це мережна файлова система, за допомогою якої можна звертатися до файлів та каталогів віддаленого комп'ютера (сервера), начебто ці файли та каталоги були локальними. Головною перевагою такої системи є те, що окремо взяті робочі станції можуть використовувати менше власного дискового простору, оскільки дані, що спільно використовуються, зберігаються на окремій машині (сховище даних) і доступні для інших машин в мережі. NFS – це клієнт-серверна програма, де роль сховища покладається на сервер. Кожен учасник мережі – це NFS-клієнт, який монтує мережевий диск сервера у файловій системі.
У ролі сервера візьмемо Ubuntu 12.04.
Як клієнти будемо використовувати та тестувати Centos та Winows 7.
Master server: 192.168.2.213 (Ubuntu)
Clients: 192.168.2.72 (Centos), 192.168.2.180 (Windows)
Налаштування сервера
Для початку потрібно настроїти сервер. Так як ми будемо використовувати Ubuntu як сервер, потрібно встановити відповідний пакет
Root@ubuntu:~# apt-get install nfs-kernel-server
Після встановлення потрібного пакети у нас створилися два файли конфігурацій. З лога установки:
… Creating config file /etc/idmapd.conf with new version Creating config file /etc/default/nfs-common with new version …
У першому файлі описано user (створений при встановленні пакета) і group для участі в mapping-e (ідентифікації користувачів).
Root@ubuntu:~# cat /etc/idmapd.conf Verbosity = 0 Pipefs-Directory = /run/rpc_pipefs # set your own domain here, if id differs from FQDN minus hostname # Domain = localdomain Nobody-User = nobody Nobody-Group = nogroup
Як ми знаємо, у Linux кожен файл належить конкретному користувачеві, який має свій (UID,GID), але в Windows системах схема трохи інша. І у зв'язку з цим було придумано механізм mapping, який робить трансляцію різних користувачів з різних ОС у зрозумілий для файлової системи Linux вигляд.
Другий файл потрібен для налаштування ідентифікації Kerberos та налаштування нестандартного порту, на якому буде слухати демон. Він поки що нам не потрібен. Про налаштування Kerberos йтиметься у наступній статті.
Root@ubuntu:~# cat /etc/default/nfs-common # Якщо ви не знайдете значення для необхідних функцій, вони будуть вирішені # autodetected; це повинно бути достатньо для найбільших людей. Valid alternativas # for the NEED_ options are "yes" and "no". # Do you want to start the statd daemon? Це не потребує NFSv4. NEED_STATD= # Options for rpc.statd. # Should rpc.statd listen on a specific port? Це дуже useful # коли ви маєте port-based firewall. Для використання fixed port, set this # this variable to a statd argument like: "--port 4000 --outgoing-port 4001". # Більше інформації, вірш rpc.statd(8) or http://wiki.debian.org/SecuringNFS STATDOPTS= # Ви хочете, щоб start gssd daemon? Це потребує Kerberos mounts. NEED_GSSD=
Тепер продовжимо налаштування.
Всі каталоги для шарингу потрібно прописувати у файлі /etc/exports. Для початку створимо 2 папки в домашній директорії та закинемо в них файли. Дерево каталогів та файлів для експорту:
Root@ubuntu:~# tree /home/alex/ /home/alex/ ├── nfs_dir1 │ ├── file1_dir1 │ ├── file2_dir1 │ └── file3_dir1 ├── nfs_dir └─ ─ file3_dir2
Тепер необхідно привласнити користувача та групу для цих каталогів (беремо з файлу /etc/idmapd.conf).
Root@ubuntu:~# chown –R nobody:nogroup nfs_dir1/ root@ubuntu:~# chown –R nobody:nogroup nfs_dir2/
Спочатку зробимо експорт директорії nfs_dir1 для конкретного IP. Редагуємо файл /etc/exprots.
Root@ubuntu:~# vim /etc/exports # Для конкретного хоста (Windows) /home/alex/nfs_dir1 192.168.2.180(rw,sync,all_squash,no_subtree_check,insecure) # Для будь-якого хоста підмережі /home/alex/ .2.0/24(rw,no_root_squash,sync,no_subtree_check)
Тут наведено мінімальний набір опцій для коректної роботи сховища Windows.
- /home/alex/nfs_dir1– шлях до папки, на яку лунає доступ;
- 192.168.2.180 – IP-адреса, якій дається доступ до папки (можна вказати всю мережу, тоді запис набуде вигляду 192.168.2.0/24)
- (rw, sync, all_squash, no_subtree_check)- Набір опцій.
Популярні опції:
- rw-Читання / запис (може приймати значення ro-тільки читання);
- no_root_squash– за замовчуванням користувач root на клієнтській машині не матиме доступу до директорії сервера, що розділяється. Цією опцією ми знімаємо це обмеження. З метою безпеки цього краще не робити;
- sync– синхронний режим доступу (може приймати зворотне значення – async);
- noaccess– забороняє доступ до зазначеної директорії. Може бути корисною, якщо перед цим ви задали доступ всім користувачам мережі до певної директорії, і тепер хочете обмежити доступ до піддиректорії лише деяким користувачам.
- all_squash- передбачає, що всі підключення будуть виконуватися від анонімного користувача (потрібно для клієнта Windows)
- anonuid= 1000 – прив'язує анонімного користувача до «місцевого» користувача;
- anongid= 1000 – прив'язує анонімного користувача до групи місцевого користувача.
- no_subtree_check(subtree_check)–якщо експортується підкаталог файлової системи, але не вся файлова система, сервер перевіряє, чи файл, який ви запитали, в експортованому підкаталозі. Вимкнення перевірки зменшує безпеку, але збільшує швидкість передачі даних.
- Як правило, Linux (та інші Unix-подібні операційні системи) резервують TCP і UDP порти від 1-1023 (так звані безпечні порти) для використання процесами користувача root. Щоб переконатися, що саме root ініціював віддалене підключення NFS, сервер NFS зазвичай вимагає, щоб віддалені клієнти використовували безпечні порти. Ця угода, однак, не дотримується деяких операційних систем (наприклад, Windows). У таких випадках опція insecureдозволяє клієнту NFS використовувати будь-який порт TCP/UDP. Зазвичай вона потрібна для обслуговування клієнтів Windows.
Усі доступні опції та синтаксис запису хостів, груп хостів тощо. можна почитати у мануалі
Root@ubuntu:~# exportfs –a
Тепер перевіряємо, що у нас експортувалося.
Root@ubuntu:~# exportfs -v /home/alex/nfs_dir1 192.168.2.180(rw,wdelay,all_squash,no_subtree_check,insecure) /home/alex/nfs_dir2 192.168.2.0/24(rw,wdelay,no_root_squash,no_subtree_check)
Сервер налаштований.
Налаштування клієнтів
Налаштування клієнта Windows
Якщо не було повідомлень про помилку. Можна приступити до монтування на стороні клієнта.
Для початку потрібно додати сервіс (службу-клієнта) NFS. Для цього переходячи в Пуск -> Панель управління -> Програми та компонентита натискаємо на пункт меню зліва Увімкнення або вимкнення компонентів Windows. У вікні вибираємо Клієнт для NFSі тиснемо ОК(Рис. 1).
Малюнок 1
Далі слід змонтувати диск. Для цього можна використовувати командний рядок або просто клацнути правою кнопкою миші на Мій комп'ютер і вибрати Підключення мережного диска. І ввести рядок \\192.168.2.213\home\alex\nfs_dir1. Це IP сервер і шлях до папки (рис. 2).
Малюнок 2
Якщо все добре, ми побачимо диск (рис. 3).
Малюнок 3
Те саме можна зробити, використовуючи командний рядок (рис. 4).
Малюнок 4
Можливі помилки:
Ви не зможете підключити мережевий NFS диск до Windows OS (мал. 5), якщо
1. Не встановлений клієнт NFS
2. Увімкнений (не налаштований) фаервол
3. Немає мережного доступу до сервера
4. Неправильно введено параметри монтування
5. Не налаштовано (не застосовано налаштування) експорт на сервері.
6. Додати опцію insecure у налаштуваннях експорту
Рисунок 5 – Помилка підключення NFS диску
Ви не зможете додати файл до змонтованої файлової системи (рис. 6), якщо:
1. На сервері не виставлено права папки (nobody:nogroup)
2. Не виставлено опцію all_squash у налаштуваннях експорту
3. Не виставлено опцію rw у налаштуваннях експорту
Рисунок 6 – Помилка при додаванні файлу на диск NFS
Налаштування Centos клієнта
Налаштування лінукс систем досить просте і безболісне. Потрібно просто встановити потрібні пакети та змонтувати диск. Для Centos потрібні такі пакети
# yum install nfs-utils nfs-utils-lib
# mkdir -p /mnt/nfs # mount 192.168.2.213:/home/alex/nfs_dir1 /mnt/nfs # mount /dev/mapper/vg_slave-lv_root on / type ext4 (rw) proc on /proc type proc (rw sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0" ) /dev/sda1 на /boot type ext4 (rw) none на /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc на /var/lib/nfs/rpc_pipefs rpc_pipefs (rw) 192.1. alex/nfs_dir1 on /mnt/nfs type nfs (rw,vers=4,addr=192.168.2.213,clientaddr=192.168.2.72)
В даному випадку ми можемо додавати будь-який файл та директорію до змонтованої nfs_dir1 папки від імені будь-якого користувача системи ( all_squash). Але якщо ми змонтуємо другу папку nfs_dir2, то в неї може записувати ТІЛЬКИ root, тому що там стоїть опція no_root_squash. Перевіряємо.
# mkdir /mnt/dir1 # mkdir /mnt/dir2 # mount 192.168.2.213:/home/alex/nfs_dir1 /mnt/dir1 # mount 192.168.2.213:/home/alex/nfs_dir2 /mnt/dir2 -o rw,hard,intr,bg 192.168.2.213:/home/alex/nfs_dir2 /mnt/dir2 # echo "Hello" > /mnt/dir1/file1 # echo "Hello" > /mnt/dir2/file1 # su alex $ echo "Hello" > /mnt/dir1/file1 $ echo "Hello" > /mnt/dir2/file1 bash: /mnt/dir2/file1: Permission denied
Можливі прапори змонтування.
| Прапор | Опис |
| rw | Монтування файлової системи для читання/запису (вона має експортуватися сервером у режимі читання/запису) |
| го | Монтування файлової системи лише для читання |
| bg | Якщо змонтувати файлову систему не вдається (сервер не відповідає), перевести операцію у фоновий режим і продовжити обробку інших запитів на монтування |
| hard | Якщо сервер вимкнувся, операції, які намагаються отримати доступ до нього, блокуються доти, доки сервер не ввімкнеться знову |
| soft | Якщо сервер вимкнувся, операції, які намагаються отримати доступ до нього, завершуються видачею повідомлення про помилку. Цей прапор корисно встановлювати для того, щоб запобігти зависанню процесів у разі невдалого монтування не дуже важливих файлових систем |
| intr | Дозволяє переривати з клавіатури заблоковані операції (видаватимуться повідомлення про помилку) |
| nointr | Не дозволяє переривати з клавіатури заблоковані операції |
| retrans=n | Вказує, скільки разів потрібно повторити запит, перш ніж буде видано повідомлення про помилку (для файлових систем, змонтованих із прапором soft) |
| timeo=n | Задає інтервал тайм-ауту для запитів (у десятих частках секунди) |
| rsize=n | Задає розмір буфера читання рівним n байт |
| wsize=fl | Задає розмір буфера запису, що дорівнює n байт |
| sec=режим | Встановлює режим безпеки |
| vers=n | Вказує версію протоколу NFS |
| proto = протокол | Вибирає транспортний протокол; їм має бути протокол tcp для версії NVS 4 |
Також можна перевірити з консолі, чи сервер експортував файлову систему.
Root@centos ~# showmount -e 192.168.2.213 Export list for 192.168.2.213: /home/alex/nfs_dir2 192.168.2.0/24 /home/alex/nfs_dir1 192.168.2.180
Додаємо монтування в автозавантаження
# cat /etc/fstab ... 192.168.2.213:/home/alex/nfs_dir2 /mnt/dir2 nfs4 rw,bg,intr,hard,nodev,nosuid 0 0
Root@centos ~# mount -a -t nfs4
Можливі помилки.
Root@centos ~# mount -a -t nfs4 mount.nfs4: mount point /mnt/dir2 немає exist root@centos ~# mount -a -t nfs4 mount.nfs4: remote share not in "host:dir" format
У першому випадку потрібно створити папку. У другому – синтаксичні помилки у fstab.
Якщо виникли помилки при монтуванні NFS розділів – пройдіть за списком Можливі помилкиіз попереднього розділу.
Для монтування розділів NFS можна також використовувати autofs. Про що йтиметься у .
Мережева файлова система NFS або Network File System, це популярний протокол мережної файлової системи, який дозволяє користувачам підключати віддалені мережеві каталоги на своїй машині та передавати файли між серверами. Ви можете використовувати дисковий простір на іншій машині для своїх файлів і працювати з файлами на інших серверах. По суті, це альтернатива загального доступу Windows для Linux, на відміну від Samba, реалізована на рівні ядра і працює стабільніше.
У цій статті буде розглянуто встановлення nfs в Ubuntu 16.04. Ми розберемо встановлення всіх необхідних компонентів, налаштування спільної папки та підключення мережевих папок.
Як було зазначено, NFS, це мережна файлова система. Для роботи необхідний сервер, на якому буде розміщено спільну папку та клієнтів, які можуть монтувати мережну папку як звичайний диск у системі. На відміну від інших протоколів, NFS надає прозорий доступ до віддалених файлів. Програми будуть бачити файли як у звичайній файловій системі і працювати з ними як з локальними файлами, nfs повертає тільки запитувану частину файлу, замість файлу цілком, тому ця файлова система буде працювати в системах зі швидким інтернетом або в локальній мережі.
Встановлення компонентів NFS
Перед тим, як ми зможемо працювати з NFS, нам доведеться встановити кілька програм. На машину, яка буде сервером, потрібно встановити пакет nfs-kernel-server, за допомогою якого буде виконано відкриття кулі nfs в ubuntu 16.04. Для цього виконайте:
sudo apt install nfs-kernel-server
Тепер давайте перевіримо, чи правильно встановився сервер. NFS слухає з'єднання як для TCP, так і для UDP на порту 2049. Подивитися чи дійсно зараз використовуються ці порти можна командою:
rpcinfo-p | grep nfs
Також важливо перевірити чи підтримується NFS на рівні ядра:
cat /proc/filesystems | grep nfs
Бачимо, що працює, але якщо ні, потрібно вручну завантажити модуль ядра nfs:
Давайте ще додамо nfs в автозавантаження:
sudo systemctl enable nfs
На клієнтському комп'ютері потрібно встановити пакет nfs-common, щоб мати можливість працювати з цією файловою системою. Вам необов'язково встановлювати компоненти сервера, достатньо лише цього пакета:
sudo apt install nfs-common
Налаштування сервера NFS в Ubuntu
Ми можемо відкрити NFS доступ до будь-якої папки, але давайте створимо для цього нову:
адреса_папки клієнт (опції)
Адреса папки - це та папка, яку потрібно зробити доступною через мережу. Клієнт - ip-адреса або адреса мережі, з якої можуть отримати доступ до цієї папки. А ось із опціями трохи складніше. Розглянемо деякі з них:
- rw- дозволити читання та запис у цій папці
- ro- дозволити лише читання
- sync- відповідати на наступні запити лише тоді, коли дані будуть збережені на диск (за замовчуванням)
- async- не блокувати підключення поки дані записуються на диск
- secure- використовувати для з'єднання тільки порти нижче 1024
- insecure- Використовувати будь-які порти
- nohide- не приховувати піддиректорії при відкритті доступу до кількох директорій
- root_squash- підміняти запити від root на анонімні
- all_squash- перетворювати всі запити на анонімні
- anonuidі anongid- Вказує uid і gid для анонімного користувача.
Наприклад, для нашої папки цей рядок може виглядати так:
/var/nfs 127.0.0.1(rw, sync, no_subtree_check)
Коли все було налаштовано, залишилося оновити таблицю експорту NFS:
sudo exportfs -a
Ось і все, відкриття кулі nfs в ubuntu 16.04 завершено. Тепер спробуємо настрої клієнта і спробуємо її примонтувати.
Підключення NFS
Ми не будемо докладно зупинятись на цьому питанні у сьогоднішній статті. Це досить велика тема, яка заслуговує на окрему статтю. Але пару слів я все ж таки скажу.
Щоб підключити мережну папку вам не потрібен ніякий nfs клієнт ubuntu, достатньо використовувати команду mount:
sudo mount 127.0.0.1:/var/nfs/ /mnt/
Тепер ви можете спробувати створити файл у підключеній директорії:
Також ми перегляньте підключені файлові системи за допомогою df:
127.0.0.1:/var/nfs 30G 6,7G 22G 24% /mnt
Щоб вимкнути цю файлову систему, достатньо використовувати стандартний umount:
sudo umount /mnt/
Висновки
У цій статті було розглянуто налаштування nfs ubuntu 16.04, як бачите, все робиться дуже просто та прозоро. Підключення NFS кулі виконується в кілька кліків, за допомогою стандартних команд, а відкриття кулі nfs в ubuntu 16.04 не набагато складніше за підключення. Якщо у вас залишилися питання, пишіть у коментарях!
Схожі записи:
