NFS дозволяє надати спільний доступ до каталогів Unix-машини. Небезпека NFS, і зокрема NIS, пов'язана з RPC - за кількістю різноманітних експлоїтів RPC є негласним лідером (якщо не вважати Sendmail). Так як ці протоколи призначені для внутрішніх мереж, захищати їх доведеться від своїх користувачів. Хоча перед їх застосуванням потрібно вирішити, чи вони дійсно потрібні.

У домашній мережі вони можуть бути досить корисними, але в корпоративній мережі з міркувань безпеки краще знайти більш безпечну альтернативу.

Файлова система NFS.

Мережева файлова система (Network File System, NFS) була розроблена компанією Sun як засіб доступу до файлів, розміщених на інших Unix-машинах у межах локальної мережі. При розробці NFS безпека взагалі не враховувалася, що з роками спричинило багато вразливостей.

NFS може працювати за протоколом TCP або UDP, вона використовує систему RPC, а це означає, що повинні бути запущені такі вразливі програми: portmapper, nfs, nlockmgr (lockd), rquotad, statd і mountd.

Не треба запускати NFS – потрібно знайти альтернативне рішення. Якщо ж NFS таки потрібна, тут буде розказано про те, як потрібно мінімізувати ризик її використання.

/etc/exports

Перший крок полягає у виборі машин, які експортуватимуть свої файлові системи. Потім можна визначити, яким машинам допускається підключатися до NFS-серверів (або серверу, якщо він один) мережі. Не потрібно використовувати NFS на машинах, які безпосередньо (безпосередньо) підключені до Інтернету. Після того, як будуть вибрані машини, потрібно вибрати каталоги на цих машинах, які будуть експортовані.

Каталоги експорту визначаються у файлі /etc/exports. Формат кожного запису простий: ім'я каталогу, список користувачів, яким дозволено доступ та режим доступу. Наприклад:

Повний доступ (читання/запис) до каталогу /home/user дозволено машині з IP-адресою 10.0.0.6. Найкраще - це давати повний доступ, а обмежитися доступом «тільки читання» (rо). Крім цього, можна також вказати такі опції:

• Secure- запит на монтаж (mount) повинен виходити з привілейованого порту (з номером до 1024). Це означає, що команду на монтування ввів користувач із привілеями root.
• Root_squash- запит користувача root розцінюватиметься як запит анонімного користувача. Це дозволяє заподіяти найменшу шкоду системі. Ця опція має бути увімкнена.
• All_squash- всі запити (не тільки від користувача root) будуть розцінюватися як вихідні від анонімного користувача. Корисно застосовувати для каталогів, що публічно експортуються.

Якщо крекер з правами root отримає доступ до машини, якій дано rw-доступ до каталогу, вказаному в /etc/exports, він отримає повний контроль над файловою системою, тому не можна експортувати кореневий каталог (/), і системно-важливі каталоги, наприклад /usr, /bin, /sbin, /lib, /opt та /etc. Добре для експорту підходять домашні каталоги користувачів.

З боку клієнта монтування загальної файлової системи потрібно виконувати вказівкою опції про nosuid:

# mount -t nfs -про nosuid 10.0.0.3:/home/user/files /mnt/home/frank

Це не дасть крекеру, який отримав доступ до NFS-сервера, отримати root-доступ до клієнтів.

Обмеження доступу.

Незалежно від сервісу для обмеження доступу до машини необхідно використовувати IPTables. У випадку з NFS-сервером, це особливо важливо. При застосуванні IPTables слід пам'ятати, що NFS-демон використовує порт 2049/TCP/UDP.

Деякі RPC-сервіси, наприклад portmapper і NFS, використовують постійні порти (113 і 2049/tcp/udp відповідно), але в інших RPC-сервісів порти не постійні, що ускладнює фільтрацію пакетів за допомогою IPTables. Єдине, що відомо, це те, що RPC використовують порти в діапазоні 32768-65535.

Якщо використовується ядро ​​2.4.13 або новіше, то за допомогою опції -р<порт>можна вказати порт для кожного RPC-сервісу.

Розглянемо функцію start() з файлу /etc/rc.d/init.d/nfslock, яка використовується для запуску nsflock:

start () (

#. Start daemons.

if ["$ USERLAND_LOCKD"]; then

echo -n $"Starting NFS locking: "

daemon rpc.lockd

echo -n $"Starting NFS statd: "

daemon rpc.statd

echo [ $RETVAL -eq 0 ] && touch /var/touch/lock/subsys/nfslock

return $RETVAL )

Для того, щоб змусити демон statd використовувати конкретний порт, можна використовувати опцію -р, наприклад daemon rpc.statd -p 32800 (або будь-який інший - який більше подобається). Так само потрібно встановити порт для mountd, nfsd, rquotad - усі вони запускаються зі сценарію /etc/rc.d/init.d/nfs:

start () (

# Start daemons.

action -n $"Starting NFS services: " /usr/sbin/exportfs -r

if t _x /usr/sbin/rpc.quotad]; then echo -n $"Starting NFS quotas: " daemon rpc.rquotad echo

fi echo -n $"Starting NFS mountd: "

daemon rpc.mountd 3RPCMOUNTDOPTS

echo -n $"Starting NFS daemon: " daemon rpc.nfsd $RPCNFSDOPTS echo touch /var/lock/subsys/nfs

Технологія зміни порту для lockd (nlockmgr) відрізняється від наведеної вище (не треба намагатися змінити файл /etc/rc.d/init.d/nfslock - нічого не вийде).

Lockd виконаний або як модуль ядра, або вкомпільований в ядро ​​статично. Для зміни номера порту треба відкрити файл /etc/modules і знайти опції, що передаються модулю:

options lockd nlm_udpport=33000 nlm_tcpport=33000

Тепер коли RPC-сервіси використовують статичні порти, які відомі, треба застосовувати IPTables. У наступному наборі правил передбачається, що NFS - єдиний запущений на машині сервер, доступ до якого дозволено лише машинам, перерахованим у файлі /usr/local/etc/nfsexports.hosts:

IPX = "/usr/sbin/iptables"

# Очищаємо всі ланцюжки

$IPT --flush

$IPT -t nat --flush $IPT -t mangle --flush $IPT -X

# Дозволяємо loopback-трафік $IPT -A INPUT -i lo -j ACCEPT $IPT -A OUTPUT -o lo -j ACCEPT

# Правила за промовчанням $IPT -P INPUT DROP $IPT -P OUTPUT DROP $IPT -P FORWARD DROP

$IPT -A INPUT -m state -state ESTABLISHED,RELATED -j ACCEPT $IPT -A OUTPUT -m state -state NEW,ESTABLISHED,RELATED -j ACCEPT

# Дозволяємо доступ кожному комп'ютеру,

# вказаному в /usr/local/etc/nfsexports.hosts

for host in "cat /usr/local/etc/nfsexports.hosts"; do $IPT -I INPUT -s $host -p tcp -dport 111 -j ACCEPT

$IPT -I INPUT -s $host -p udp -dport 111 -j ACCEPT

$IPT -I INPUT -s $host -p udp -dport 2049 -j ACCEPT

$IPT -I INPUT -s $host -p tcp --dport 32800 -j ACCEPT

$IPT -I INPUT -s $host -p tcp --dport 32900 -j ACCEPT

$IPT -I INPUT -s $host -p tcp -dport 33000 -j ACCEPT

$IPT -I INPUT -s $host -p tcp --dport 33100 -j ACCEPT

Звичайно, це лише скелет, потрібно буде додати ще багато правил: хоча б дозволити застосування SSH та встановити деякі параметри ядра за допомогою / prос.

Тунелювання NFS через SSH.

Абревіатура NFS іноді розшифровується як "No File Security" - дані три слова говорять самі за себе. Тому дуже важливо забезпечити захист NFS-трафіку. Це легко зробити за допомогою ssh.

Спочатку можна змінити файл /etc/exports на сервері NFS так, щоб файлові системи експортувалися локальному вузлу:

Потім слід застосовувати SSH для форвардингу портів NFS і mountd. NFS використовує порт 2049/udp, a mountd, як було зазначено, порт із номером 33000:

# ssh [email protected]-L 200: localhost:2049 -f sleep 120m

# ssh [email protected]-L 200: localhost:33000 -f sleep 120m

Дані дві команди надають користувачеві інтерактивну оболонку, але оскільки вона не потрібна, SSH виконує команду sleep 120: повертаємося назад в командний рядокАле форвардинг портів триватиме ще 2 години.

Монтування файлової системи клієнта виглядає дуже незвичайно:

mount -t nfs -про nosuid port=200 mountport=210 nfsserver.test.net:/home/user /mnt/another

Якщо трюки з ssh-тунпелированием занадто складні, можна використовувати проект SHFS (Shell Filesystem) ( http://shfs.sourceforge.net/ ), який дозволяє автоматизувати всю цю процедуру.

Після встановлення отримати доступ до SHFS треба або за допомогою команди mount-t shfs, або за допомогою нової команди shfsmount. Синтаксис цієї команди схожий на попередній:

shfsmount [email protected]:/home/user /mnt/user

CFS та TCFS

Криптографічна файлова система (Cryptographic File System) використовує прозоре кодування та дешифрування NFS-трафіку за допомогою алгоритму DES. Крім цього, вона підтримує автоматичне керування ключами, що робить процес максимально прозорим для користувача.

Хоча CFS розроблена для SunOS і BSD, вона дуже цікава, тому що представляється першою спробою «прозорого» кодування спільних файлів. Прозора криптографічна файлова система (Transparent Cryptographic File System, TCFS) надає ще прозоріший спосіб кодування NFS-трафіку.

Крім кодування даних, файлова система підтримує перевірку цілісності даних.

N FS ( Network File System) в основному розроблена для спільного використання файліві папокміж / Unixсистем від компанії Sun Microsystemsв 1980 року. Вона дозволяє монтувати локальні файлові системи по мережі та віддалених хостів, для взаємодії з ними так, ніби вони встановлені локально на тій самій системі. За допомогою NFS, ми можемо налаштувати спільний доступ до файлів між Unixв Linuxсистемі та Linuxдля системи Unix.

Переваги NFS

1. NFSстворює локальний доступдо віддаленим файлам.
2. Він використовує стандартну архітектуру клієнт/сервердля обміну файлами між усіма машинами на базі * NIX.
3. За допомогою NFSне потрібно, щоб обидві машини працювали на тій самій ОС.
4. За допомогою NFSми можемо налаштувати рішення централізованого зберігання.
5. Користувачі отримують свої данінезалежно від їхнього фізичного розташування.
6. Автоматичне оновленнядля нових файлів.
7. Новіша версія NFSпідтримує монтування acl, pseudoпід root.
8. Може бути захищений брандмауерамиі Kerberos.

Послуги NFS

Сервіс System V-launched. Серверний пакет NFSвключає три засоби, що входять до складу пакетів portmapі nfs-Utils.

1. portmap: відображає дзвінки з інших машин до правильної служби RPC(не потрібно з NFSv4).
2. nfs: перетворює віддалені запити загального доступудо файлівзапити на локальній файловій системі.
3. rpc.mountd: ця служба відповідає за монтуванняі розмонтуванняфайлових систем

Важливі конфігураційні файли для NFS

1. /etc/exports: його основний конфігураційний файл NFS, всі експортовані файлиі каталоги, які визначені в цьому файлі та на кінцевому сервері NFS.
2. /etc/fstab: Для того, щоб змонтувати каталог NFSна вашій системі без перезавантаженьнам потрібно зробити запис в /etc/fstab.
3. /etc/sysconfig/nfs: Конфігураційний файл NFSдля управління, на якому порт RPCта інші послуги прослуховування.

Налаштування та монтування NFS на сервері Linux

Для налаштування монтування NFS, ми будемо потребувати принаймні двох машин Linux/Unix. Ось у цьому підручнику, ми будемо використовувати два сервери.

1. Сервер NFS: nfsserver.example.ru з IP – 192.168.0.55
2. Клієнт NFS: nfsclient.example.ru з IP – 192.168.0.60

Встановлення сервера NFS та клієнта NFS

Нам потрібно встановити пакети NFSна нашому сервері NFS, а також на машині клієнта NFS. Ми можемо встановити його за допомогою “ ” ( Red Hat Linux) та інсталяційний пакет “ apt-get” (Debianі Ubuntu).

# yum install nfs-utils nfs-utils-lib # yum install portmap (не потребує NFSv4) # apt-get install nfs-utils nfs-utils-lib

Тепер запустіть службина обох машинах.

# /etc/init.d/portmap start # /etc/init.d/nfs start # chkconfig --level 35 portmap on # chkconfig --level 35 nfs on

Після встановлення пакетів та запуску сервісів на обох машинах, нам потрібно налаштувати обидві машини для спільного використання файлів.

Налаштування сервера NFS

Спочатку налаштуємо сервер NFS.

Налаштування каталогу експорту

# mkdir /nfsshare

Тепер нам потрібно зробити запис у “ /etc/exports” та перезапуститислужби, щоб зробити наш каталог поділюваними в мережі.

# vi /etc/exports /nfsshare 192.168.0.60(rw, sync, no_root_squash)

У наведеному вище прикладі є каталог, в розділі / під назвою " nfsshare", в даний час спільно з клієнтом IP" 192.168.0.60 ” з привілеями читанняі записи (RW), ви можете також використовувати ім'я хостаклієнта замість IPу наведеному вище прикладі.

Параметри NFS

Деякі інші варіанти ми можемо використовувати у файли “ /etc/exports” для спільного використання файлів виглядає так.

1. ro: За допомогою цієї опції ми можемо надати доступ тільки для читаннядо загальних файлів, тобто клієнтбуде тільки в стані прочитати.
2. rw: Ця опція дозволяє клієнт – серверудоступ для обох для читанняі записиу межах загального каталогу.
3. sync: Синхронізація підтверджує запити до спільного каталогу тільки після того, як змінибули скоєні.
4. no_subtree_check: Ця опція запобігає перевірці піддерева. Коли загальний каталог є підкаталогом більшої файлової системи, NFSвиконує сканування кожної директорії над ним, щоб перевірити свої дозволи та деталі. Вимкнення перевірки піддереваможе підвищити надійність NFS, але знижують безпека.
5. no_root_squash: Ця фраза дозволяє root, підключитисядо певної папки.

Для більшої кількості варіантів з “ /etc/exports“, рекомендується прочитати сторінкикерівництва для експорту.

Налаштування клієнта NFS

Після налаштування NFS-Сервера, нам необхідно змонтуватицей загальний каталог або розділ на клієнтськоюсервер.

Монтування спільних каталогів на клієнті NFS

Тепер на клієнт NFS, нам потрібно змонтуватицей каталог доступу до нього на місцевому рівні. Для цього ми повинні з'ясувати, які ресурси доступні на віддаленому сервері або сервері NFS.

# showmount -e 192.168.0.55 Export list for 192.168.0.55: /nfsshare 192.168.0.60

Монтування доступного каталогу в NFS

Для того щоб змонтуватизагальний NFSкаталог, ми можемо використати наступну команду монтування.

# mount -t nfs 192.168.0.55:/nfsshare /mnt/nfsshare

Наведена вище команда встановить загальний каталог у “ /mnt/nfsshare” на сервері клієнта. Ви можете перевірити його наступною командою.

# Mount | grep nfs sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) nfsd on /proc/fs/nfsd type nfsd (rw) 192.168.0.55:/nfsshare on /mnt8type.

Вище команда mount монтує на NFS спільно використовуваний каталогна NFS клієнтатимчасово змонтувати каталог NFS постійнона вашій системі незалежно від перезавантажень, нам потрібно зробити запис у “ /etc/fstab“.

# vi /etc/fstab

Додайте наступний новий рядок, як показано нижче.

192.168.0.55:/nfsshare /mnt nfs defauls 0 0

Тестування режиму роботи NFS

Ми можемо протестувати нашу встановлення сервера NFSшляхом створення тестового файлуна стороні сервера і перевірити його наявність на NFS клієнтастороні чи навпаки.

На стороні сервера nfsserver

Ми створили новий текстовий файл з ім'ям “ nfstest.txt” у цьому загальному каталозі.

# cat > /nfsshare/nfstest.txt Це є файл тесту для роботи з NFS server setup.

На стороні клієнта nfsclient

Перейдіть до загального каталогу на сервері клієнтаі ви знайдете спільний файл без будь-якого ручного оновлення або служби перезавантаження.

# ll /mnt/nfsshare total 4 -rw-r--r-- 1 root root 61 Sep 21 21:44 nfstest.txt root@nfsclient ~]# cat /mnt/nfsshare/nfstest.txt test the working of NFS server setup.

Видалення монтування NFS

Якщо ви хочете розмонтуватицей загальний каталог із сервера після того, як ви закінчите з обміном файлами, ви можете просто розмонтуватицей конкретний каталог за допомогою команди umount“. Дивіться цей приклад.

Root@nfsclient ~]# umount /mnt/nfsshare

Ви можете бачити, що монтування видалено у файловій системі.

# df -h -F nfs

Ви побачите, що ці загальні каталоги більше не доступні.

Важливі команди для NFS

Деякі важливіші команди для NFS .

1. showmount -e: Показує доступні розшаровані об'єктина локальному комп'ютері
2. showmount -e : Список доступних розшарованих об'єктівна віддаленомусервері
3. showmount -d: Список всіх піддиректорій
4. exportfs -v: Відображає список розшарованих файліві опційна сервері
5. exportfs -a: Експорт усіх доступних об'єктів, перерахованих у /etc/exports, або ім'я
6. exportfs -u: Реекспорт усіх доступних об'єктів, перераховані в /etc/exports, або ім'я
7. exportfs -r: Оновити список сервера після зміни /etc/exports

Це все про монтування NFSна Наразі, якщо цікаво, можете прочитати гід про те. Залишайте свої

#image.jpgНепоганого часу, читачі та гості мого блогу. Дуже велика перерва між постами була, але я знову в бою). У сьогоднішній статті розгляну роботу протоколу NFS, а також налаштування сервера NFS та клієнта NFS на Linux.

Вступ до NFS

NFS (Network File System- Мережева файлова система) на мою думку - ідеальне рішенняв локальній мережі, де потрібен швидкий (швидший у порівнянні з SAMBA і менш ресурсомісткий в порівнянні з віддаленими файловими системами з шифруванням - sshfs, SFTP, etc ...) обмін даними і на чолі не стоїть безпека переданої інформації. Протокол NFSдозволяє монтувати видалені файлові системи через мережу в локальне дерево каталогів, як це була примонтована дискова файлова система.

Тим самим локальні програми можуть працювати з віддаленою файловою системою, як з локальною. Але потрібно бути обережним (!) з налаштуванням NFS, бо за певної конфігурації можна підвісити операційну систему клієнта в очікуванні нескінченного вводу/вывода.

Протокол NFSзаснований на роботі протоколу RPC, який поки що не піддається моєму розумінню)) тому матеріал у статті буде трохи розпливчастий... Перш ніж Ви зможете використовувати NFS, чи це сервер або клієнт, Ви повинні переконатися, що Ваше ядро ​​має підтримку файлової системи NFS. Перевірити чи підтримує ядро ​​файлову систему NFS можна, переглянувши наявність відповідних рядків у файлі /proc/filesystems:

ARCHIV ~ # grep nfs /proc/filesystems nodev nfs nodev nfs4 nodev nfsd

Якщо зазначених рядків у файлі /proc/filesystems не виявиться, необхідно встановити наведені нижче пакети. Це швидше за все дозволить встановити залежні модулі ядра підтримки підходящих файлових систем.

Якщо після інсталяції пакетів, підтримка NFS не буде відображена у зазначеному файлі, то необхідно буде перекомпілювати ядро, з увімкненням цієї функції.

Історія Network File System

Протокол NFSрозроблений компанією Sun Microsystems і має у своїй історії Чотири версії. NFSv1 була розроблена в Одна тисяча дев'ятсот вісімдесят дев'ять і була експериментальною, працювала на протоколі UDP. Версія Один описана RFC 1094.

NFSv2 була випущена в тому ж Одна тисяча дев'ятсот вісімдесят дев'ять р., описувалася тим же RFC1094 і так само базувалася на протоколі UDP, при цьому дозволяла читати менше 2Гб з файлу. NFSv3 дороблена в Одна тисяча дев'ятсот дев'яносто 5 р. і описана RFC 1813.

Основними нововведеннями третьої версії стало підтримка файлів великого розміру, додана підтримка протоколу TCP і TCP-пакетів величезного розміру, що прискорило працездатність технології. NFSv4 дороблена в Дві тисячі років і описана в RFC 3010, в Дві тисячі три роки переглянута і описана в RFC 3530.

Четверта версія включила поліпшення продуктивності, підтримку різних засобів автентифікації (зокрема, Kerberos і LIPKEY з допомогою протоколу RPCSEC GSS) і списків контролю доступу (як POSIX, і Windows-типів). NFS версії v4.1 була схвалена IESG у Дві тисячі 10 р., та отримала номер RFC 5661.

Принципним нововведенням версії 4.1 є специфікація pNFS - Parallel NFS, механізму паралельного доступу NFS-клієнта до даних безлічі розподілених NFS-серверів. Наявність такого механізму у зразку мережної файлової системи допоможе будувати розподілені «хмарні» (cloud) сховища та інформаційні системи.

NFS сервер

Бо в нас NFS- це мережевафайлова система, то необхідно налаштувати мережау Linux. (Так само можна почитати статтю основні поняття мереж). Далі необхідно встановити відповідний пакет. У Debian це пакет nfs-kernel-server і nfs-common, у RedHat це пакет nfs-utils.

Також необхідно дозволити запуск демона на відповідних рівнях виконання (команда в RedHat - /sbin/chkconfig nfs on, в Debian - /usr/sbin/update-rc.d nfs-kernel-server defaults).

Установлені пакети в Debian запускаються в наступному порядку:

ARCHIV ~ # ls -la /etc/rc2.d/ | grep nfs lrwxrwxrwx Один root root 20 Жов Вісімнадцять 15:02 S15nfs-common -> ../init.d/nfs-common lrwxrwxrwx Один root root 20 сім Жов 20 два 01:23> S1. .d/nfs-kernel-server

Іншими словами, спочатку запускається nfs-common, пізніше сам сервер nfs-kernel-server.

У RedHat ситуація схожа, за тим лише винятком, що перший скрипт називається nfslock, а сервер називається просто nfs. Про nfs-commonнам сайт debian дослівно говорить таке: спільні файли для клієнта та сервера NFS, цей пакет потрібно встановлювати на машину, яка буде працювати як клієнт або сервер NFS.

У пакет включені програми: lockd, statd, showmount, nfsstat, gssd та idmapd. Переглядаючи вміст скрипту запуску /etc/init.d/nfs-common, можна відстежити наступну послідовністьроботи: скрипт перевіряє наявність виконуваного бінарного файлу /sbin/rpc.statd, перевіряє наявність у файлах /etc/default/nfs-common, /etc/fstab і /etc/exports характеристик, що вимагають запуск бісів idmapdі gssd, запускає демона /sbin/rpc.statd, далі перед запуском /usr/sbin/rpc.idmapd та /usr/sbin/rpc.gssd перевіряє наявність цих виконуваних бінарних файлів, Далі для біса /usr/sbin/rpc.idmapd перевіряє наявність модулів ядра sunrpc, nfs і nfsd, а також підтримку файлової системи rpc_pipefs в ядрі (тобто наявність її у файлі /proc/filesystems), якщо все вдало, то запускає /usr/sbin/rpc.idmapd. Додатково для біса /usr/sbin/rpc.gssdперевіряє модуль ядра rpcsec_gss_krb5 і запускає біс.

Якщо переглянути вміст скрипта запуску NFS-серверана Debian (/etc/init.d/nfs-kernel-server), можна простежити таку послідовність: при старті, скрипт перевіряє існування файлу /etc/exports, наявність модуля ядра nfsd, наявність підтримки файлової системи NFS в ядрі Linux (іншими словами у файлі /proc/filesystems), якщо все на місці, то запускається біс /usr/sbin/rpc.nfsd, далі перевіряє заданий параметр NEED_SVCGSSD (задається у файлі опцій сервера /etc/default/nfs-kernel-server) і, якщо заданий - запускає біса /usr/sbin/rpc.svcgssd, останнім запускає біса /usr/sbin/rpc.mountd. З даного скриптувидно що робота сервера NFS складається збісів rpc.nfsd, rpc.mountd і якщо використовується Kerberos-автентифікація, то і біс rcp.svcgssd. У червоному капелюсі ще запускається демон rpc.rquotad і nfslogd (У Debian я чомусь не знайшов інформації про цього демона і про причини його відсутності, мабуть видалений ...).

З цього стає зрозуміло, що сервер Network File System складається з наступних процесів (читай - бісів), розташованих у каталогах /sbin та /usr/sbin:

• rpc.statd- Біс спостереження за мережевим станом (він Network Status Monitor, він же NSM). Він дозволяє коректно скасовувати блокування після збою/перезавантаження. Для повідомлення про порушення використовує програму /usr/sbin/sm-notify. Бес statd працює як на серверах, так і на клієнтах. Раніше цей сервер був потрібен для роботи rpc.lockd, але за блокування зараз відповідає ядро ​​(якщо я не помиляюся #image.jpg). (RPC програма 100 тисяч 20 один і 100 тисяч 20 чотири - у нових версіях)
• rpc.lockd- Бес блокування lockd (він же NFS lock manager (NLM)) обробляє запити на блокування файлів. Біс блокування працює як на серверах, так і на клієнтах. Клієнти запитують блокування файлів, а сервери його дозволяють. (застарілий і в нових дистрибутивах не вживається як біс. Його функції в сучасних дистрибутивах (з ядром старше 2.2.18) виконуються ядром, точніше модулем ядра (lockd).) (RPC програма 100024)
• rpc.nfsd- Основний біс сервера NFS - nfsd (у нових версіях часом називається nfsd4). Цей біс обслуговує запити клієнтів NFS. Параметр RPCNFSDCOUNT у файлі /etc/default/nfs-kernel-server у Debian і NFSDCOUNT у файлі /etc/sysconfig/nfs у RedHat визначає кількість бісів, що запускаються (за замовчуванням - 8).(RPC програма 100003)
• rpc.mountd- Бес монтування NFS mountd обробляє запити клієнтів на монтування каталогів. Біс mountd працює на серверах NFS. (RPC програма 100005)
• rpc.idmapd- Біс idmapd для NFSv4 на сервері перетворює локальні uid/gid користувачів у формат виду ім'я@домен, а сервіс на клієнті перетворює імена користувачів/груп виду ім'я@домен на локальні ідентифікатори користувача та групи (відповідно до конфігураційного файлу /etc/idmapd.conf, детальніше man idmapd.conf):.
• додатково, у старих версіях NFS використовувалися біси: nfslogd- біс журналів NFS фіксує активність для експортованих файлових систем, працює на серверах NFS та rquotad- сервер віддалених квот надає інформацію про квоти користувачів у віддалених файлових системах, може працювати як на серверах, так і на клієнтах. (RPC програма 100011)

У NFSv4 при використанні Kerberos додатково запускаються біси:

• rpc.gssd- Біс NFSv4 забезпечує методи аутентифікації через GSS-API (Kerberos-аутентифікація). Працює на клієнті та сервері.
• rpc.svcgssd- Біс сервера NFSv4, який забезпечує автентифікацію клієнта на стороні сервера.

portmap та протокол RPC (Sun RPC)

Крім зазначених вище пакетів, для коректної роботи NFSv2 і v3 потрібно додатковий пакет portmap(у новіших дистрибутивах замінений на перейменований на rpcbind). Цей пакет зазвичай встановлюється автоматично з NFS як залежний і реалізує роботу сервера RPС, тобто відповідає за динамічне призначення портів для деяких служб, зареєстрованих в сервері RPC.

Дослівно, згідно з документацією - це сервер, який перетворює номери програм RPC (Remote Procedure Call) у номери портів TCP/UDP. portmap оперує кількома сутностями: RPC-дзвінками або запитами, TCP/UDP портами, версією протоколу (tcp або udp), номерами програм та версіями програм. Біс portmap запускається скриптом /etc/init.d/portmap до старту NFS-сервісів.

Коротко кажучи, робота сервера RPC (Remote Procedure Call) полягає в обробці RPC-дзвінків (т.зв. RPC-процедур) від локальних та віддалених процесів.

Використовуючи RPC-дзвінки, сервіси реєструють або прибирають себе в/з перетворювача портів (він же відображає порти, він же portmap, він же portmapper, він же, в нових версіях, rpcbind), а клієнти за допомогою RPC-дзвінків надсилаючи запити до portmapper отримують потрібну інформацію. Користувач-френдлі найменування сервісів програм та відповідні їм номери визначені у файлі /etc/rpc.

Як будь-який сервіс відправив відповідний запит і зареєстрував себе на сервері RPC у відображачі портів, RPC-сервер присвоює зіставляє сервісу TCP і UDP порти на яких запустився сервіс і зберігає в собі ядру відповідну інформацію про працюючий сервіс (про ім'я), унікальному номерісервісу (відповідно до /etc/rpc) , про протокол і порт у якому працює сервіс і версії сервісу і надає зазначену інформацію клієнтам на запит. Сам перетворювач портів має номер програми (100 000), номер версії - 2, TCP порт 100 одинадцять і UDP порт 111.

Вище, за вказівкою складу бісів сервера NFS я вказав головні RPC номери програм. Я, напевно, трохи заплутав Вас даним абзацом, тому вимовлю основну фразу, яка повинна внести ясність: основна функція відображача портів полягає в тому, щоб на запит клієнта, який надав номер RPC-програми (або RPC-номер програми) і версію, повернути йому (клієнту) порт, у якому працює запитана програма . Відповідно, якщо клієнту потрібно звернутися до RPC з певним номером програми, він спочатку повинен увійти в контакт з процесом portmap на серверній машині і знайти номер порту зв'язку з необхідним обслуговуванням RPC.

Роботу RPC-сервера можна представити такими кроками:

Для отримання інформації від RPC-сервера використовується утиліта rpcinfo. При вказівці характеристик -p host програма виводить список всіх зареєстрованих RPC програм на хості host. Без вказівки хоста програма виведе послуги на localhost. Приклад:

ARCHIV ~ # rpcinfo -p прог-ма верс прото порт 100 тисяч Два tcp 100 одинадцять portmapper 100 тисяч Два udp 100 одинадцять portmapper 100 тисяч 20 чотири Один udp 50 дев'ять тисяч чотириста 50 один statt20 status 100 тисяч 20 один Один udp 40 чотири тисячі триста 10 nlockmgr 10 nlockmgr1 nlockmgr 10 nlockmgr 100 тисяч 20 один Три tcp 40 чотири тисячі вісімсот 50 один nlockmgr 100 тисяч 20 один Чотири tcp 40 чотири тисячі вісімсот 50 один nlockmgr 100 тисяч три Два tcп Дві тисячі 40 дев'ять nfs 10 тисяч три Чотири tcp Дві тисячі 40 дев'ять nfs 100 тисяч три Два udp Дві тисячі 40 дев'ять nfs 100 тисяч три Три udp Дві тисячі 40 дев'ять nfs 100 тисяч три Чотири udp Дві тисячі 40 дев'ять n0 10 00 00 5 Один tcp 40 одна тисяча чотириста 5 mountd 100 тисяч 5 Два udp 50 одна тисяча триста 6 mountd 100 тисяч 5 Два tcp 40 одна тисяча чотириста 5 mountd 100 тисяч 5 Три udp 50 одна тисяча триста 6 mount 5 mountd

Як видно, rpcinfo вказує (у стовпчиках зліва направо) номер зареєстрованої програми, версію, протокол, порт та назву.

За допомогою rpcinfo можна видалити реєстрацію програми або отримати інформацію про окремий сервіс RPC (більше опцій у man rpcinfo). Як видно, зареєстровані біси portmapper версії Два на udp і tcp портах, rpc.statd версії Один на udp і tcp портах, NFS lock manager версій 1,3,4, бес nfs сервера версії 2,3,4, а також без монтування версій 1,2,3.

NFS сервер (точніше демон rpc.nfsd) отримує запити від клієнта у вигляді UDP датаграм на порт 2049. Незважаючи на те, що NFS працює з перетворювачем портів, що дозволяє серверу використовувати порти, що динамічно призначаються, UDP порт Дві тисячі 40 дев'ять жорстко закріплений за NFS у більшості реалізацій.

Робота протоколу Network File System

Монтування віддаленої NFS

Процес монтування віддаленої файлової системи NFS можна представити такою схемою:

Опис протоколу NFS при монтуванні віддаленого каталогу:

1. На сервері та клієнті запускається сервер RPC (зазвичай при завантаженні), обслуговуванням якого займається процес portmapper і реєструється на порту tcp/111 і udp/111.
2. Запускаються сервіси (rpc.nfsd, rpc.statd та ін.), які реєструються на сервері RPC і реєструються на випадкових мережевих портах (якщо в налаштуваннях сервісу не заданий статичний порт).
3. команда mount на комп'ютері клієнта відправляє ядру запит на монтування мережевого каталогу із зазначенням типу файлової системи, хоста та практично - каталогу, ядро ​​відправляє формує RPC-запит процесу portmap на NFS сервері на порт udp/111 (якщо на клієнті не задана функція працювати через tcp )
4. Ядро сервера NFS опитує RPC про наявність демона rpc.mountd і повертає ядру клієнта мережевий порт, на якому працює демон.
5. mount відправляє запит RPC на порт, на якому працює rpc.mountd. На даний момент NFS сервер може перевірити достовірність клієнта, ґрунтуючись на його IP адресі та номері порту, щоб переконатися, чи можна цьому клієнту змонтувати зазначену файлову систему.
6. Демон монтування повертає опис запитаної файлової системи.
7. Команда mount клієнта видає системний виклик mount, щоб зв'язати описувач файлу, придбаний у кроці 5 з локальною точкою монтування на хості клієнта. Описувач файлу зберігається в коді NFS клієнта, і з цього моменту будь-яке звернення процесів до файлів на файлової системі сервера використовуватиме описувач файлу як стартову точку.

Обмін даними між клієнтом та сервером NFS

Звичайний доступ до віддаленої файлової системи можна описати такою схемою:

Опис процесу звернення до файлу на сервері NFS:

Налаштування сервера NFS

Налаштування серверав цілому полягає у завданні локальних каталогів, дозволених для монтування віддаленими системамиу файлі /etc/exports. Ця дія називається експорт ієрархії каталогів. Основними джерелами інформації про експортовані каталоги служать такі файли:

• /etc/exports- Основний конфігураційний файл, що містить у собі конфігурацію експортованих каталогів. Використовується при запуску NFS та утиліті exportfs.
• /var/lib/nfs/xtab- Містить список каталогів, монтованих віддаленими клієнтами. Використовується демоном rpc.mountd, коли покупець намагається змонтувати ієрархію (створюється запис про монтування).
• /var/lib/nfs/etab- Список каталогів, які можуть бути змонтовані віддаленими системами із зазначенням всіх характеристик експортованих каталогів.
• /var/lib/nfs/rmtab- Список каталогів, які не розекспортовані в даний момент.
• /proc/fs/nfsd- особлива файлова система (ядро 2.6) керувати NFS сервером.
• exports- Список активних експортованих ієрархій і клієнтів, яким їх експортували, а також характеристики. Ядро отримує цю інформацію з /var/lib/nfs/xtab.
• threads- Містить кількість потоків (також можна змінювати)
• за допомогою filehandle можна отримати покажчик на файл
• та ін...
• /proc/net/rpc- Містить "сиру" (raw) статистику, яку можна отримати за допомогою nfsstat, також різні кеші.
• /var/run/portmap_mapping- інформація про зареєстровані в RPC сервіси

Прим:взагалі, в інтернеті купа трактувань та формулювань призначення файлів xtab, etab, rmtab, кому вірити – не знаю #image.jpg Навіть на http://nfs.sourceforge.net/ трактування не однозначне.

Налаштування файлу /etc/exports

В ординарному випадку файл /etc/exports є єдиним файлом, що вимагає редагування функції NFS-сервера. Цей файлкерує такими властивостями:

• Які клієнтиможуть звертатися до файлів на сервері
• До яких ієрархійкаталогів на сервері може звертатися кожен клієнт
• Як імена користувача користувача будуть відображатисяна локальні іменакористувачів

Будь-який рядок файлу exports має наступний формат:

точка_експорта клиент1(функции) [клиент2(функции) ...]

Де точка_експортуабсолютний шлях експортованої ієрархії каталогів, клієнт1 - nім'я одного або більше клієнтів або IP-адрес, розбиті пробілами, яким можна монтувати точку_експорту. Функціїописують правила монтування клієнта, позначеного перед опціями.

Ось звичайний приклад конфігурації файлу exports:

ARCHIV ~ # cat /etc/exports /archiv1 files(rw,sync) 10.0.0.1(ro,sync) 10.0.230.1/24(ro,sync)

У цьому прикладі комп'ютерам files і 10.0.0.1 дозволено доступ до точки експорту /archiv1, при цьому, хосту files на читання/запис, а для хоста 10.0.0.1 і підмережі 10.0.230.1/24 доступ тільки на читання.

Опис хостів у /etc/exports допускається у такому форматі:

• Імена окремих вузлів описуються як files або files.DOMAIN.local.
• Опис маски доменів робиться в наступному форматі: * DOMAIN.local включає всі вузли домену DOMAIN.local.
• Підмережі задаються у вигляді пар адрес IP/маска. Наприклад: 10.0.0.0/255.255.255.0 містить усі вузли, адреси яких починаються з 10.0.0.
• Завдання імені мережної групи @myclients, яка має доступ до ресурсу (при використанні сервера NIS)

Загальні функції експорту ієрархій каталогів

У файлі exports використовуються такі спільні функції(спочатку вказані функції, що застосовуються за замовчуванням у більшості систем, у дужках - не за замовчуванням):

• auth_nlm (no_auth_nlm)або secure_locks (insecure_locks)- Вказує, що сервер повинен домагатися аутентифікації запитів на блокування (за допомогою протоколу NFS Lock Manager (диспетчер блокування NFS)).
• nohide (hide)- Якщо сервер експортує дві ієрархії каталогів, при цьому одна вкладена (примонтована) в іншу. Клієнту необхідно очевидно змонтувати другу (дочірню) ієрархію, інакше точка монтування дочірньої ієрархії буде виглядати як порожній каталог. Функція nohide призводить до появи другої ієрархії каталогів без очевидного монтування. (прим: я цю опціютак і не зміг змусити працювати...)
• ro (rw)- Дозволяє лише запити на читання (запис). (в кінцевому підсумку - можливо прочитати/записати чи ні визначається виходячи з прав файлової системи, у своїй сервер неспроможний відрізнити запит на читання файлу від запиту виконання, тому дозволяє читання, якщо в користувача є права на читання чи виконання.)
• secure (insecure)- просить, щоб запити NFS надходили із захищених портів (< 1024), чтобы программа без прав root не могла монтировать иерархию каталогов.
• subtree_check (no_subtree_check)- Якщо експортується підкаталог фалової системи, але не вся файлова система, сервер перевіряє, чи файл, який ви запитали, в експортованому підкаталозі. Вимкнення перевірки зменшує безпеку, але збільшує швидкість передачі даних.
• sync (async)- Вказує, що сервер повинен відповідати на запити лише після запису диска конфігурацій, виконаних цими запитами. Функція async показує серверу не чекати запису інформації на диск, що збільшує продуктивність, але знижує надійність, т.к. у разі обриву з'єднання або відмови обладнання можлива втрата інформації.
• wdelay (no_wdelay)- вказує серверу затримувати виконання запитів запис, якщо очікується наступний запит запис, записуючи дані більшими блоками. Це збільшує продуктивність під час відправлення великих черг команд на запис. no_wdelay вказує не відкладати виконання команди на запис, що може бути корисно, якщо сервер отримує необмежену кількість команд, не пов'язаних спільно.

Експорт символічних посилань та файлів пристроїв.При експорті ієрархії каталогів, що містять символічні посилання, необхідно, щоб об'єкт посилання був доступний клієнтській (віддаленій) системі, тобто повинно виконуватися одне з наступних правил:

• у клієнтській файловій системі має існувати об'єкт посилання
• необхідно експортувати та змонтувати об'єкт посилання

Файл пристрою відноситься до інтерфейсу ядра Linux. Під час експорту файлу пристрою експортується цей інтерфейс. Якщо клієнтська система не має пристрою такого самого типу, то експортований пристрій не працюватиме.

У клієнтській системі, при монтуванні NFS об'єктів можна використовувати опцію nodev, щоб файли пристроїв в каталогах, що монтуються, не використовувалися.

Функції за промовчанням у різних системах можуть відрізнятися, їх можна переглянути у файлі /var/lib/nfs/etab. Після опису експортованого каталогу в /etc/exports і перезапуску сервера NFS всі функції, що відсутні (читай: функції за замовчуванням) будуть відображені у файлі /var/lib/nfs/etab.

Функції відображення (відповідності) ідентифікаторів користувачів

Для більшого розуміння сказаного нижче я б порадив ознайомитися зі статтею Управління користувачами Linux. Кожен користувач Linuxмає свої UID та головний GID, які описані у файлах /etc/passwd та /etc/group.

Сервер NFS вважає, що операційна система віддаленого вузла здійснила автентифікацію користувачів і призначила їм коректні ідентифікатори UID і GID. Експортування файлів дає користувачам системи клієнта такий самий доступ до цих файлів, якби вони реєструвалися безпосередньо на сервері. Відповідно, коли клієнт NFS посилає запит серверу, сервер використовує UID і GID для ідентифікації користувача у локальній системі, що може призводити до деяких проблем:

Наступні функції задають правила відображення віддалених користувачів локальних:

Приклад використання файлу карти користувачів:

ARCHIV ~ # cat /etc/file_maps_users # Мапінг користувачів # remote local comment uid 0-50 Одна тисяча два # зіставлення користувачів з віддаленим UID 0-50 до локального UID Одна тисяча два gid 0-50 Одна тисяча два # зіставлення користувачів с/s віддаленим GID 0-50 до локального GID 1002

Керування сервером NFS

Керування сервером NFS здійснюється за допомогою наступних утиліт:

• nfsstat
• showmsecure (insecure)ount
• exportfs

nfsstat: статистика NFS та RPC

Утиліта nfsstat дозволяє переглянути статистику RPC і NFS серверів. Функції команди можна переглянути в man nfsstat.

showmount: виведення інформації про стан NFS

Утиліта showmountзапитує бес rpc.mountd на віддаленому хості про змонтовані файлові системи. За промовчанням видається відсортований список клієнтів. Ключі:

• --all- Видається список клієнтів та точок монтування із зазначенням куди клієнт примонтував каталог. Ця інформація може бути ненадійною.
• --directories- Видається список точок монтування
• --exports- видається список файлових систем, що експортуються, виходячи з переконань nfsd

При запуску showmount без аргументів на консоль буде виведена інформація про системи, яким дозволено монтувати локальнізбірники. Наприклад, хост ARCHIV нам надає список експортованих каталогів з IP-адресами хостів, яким дозволено монтувати зазначені збірники:

FILES ~ # showmount --exports archiv Export list for archiv: /archiv-big 10.0.0.2 /archiv-small 10.0.0.2

Якщо вказати в аргументі ім'я хоста/IP, то буде виведена інформація про цей хост:

ARCHIV ~ # showmount files clnt_create: RPC: Program not registered # це повідомлення каже нам, що на хості FILES бес NFSd не запущено

exportfs: керування експортованими каталогами

Ця команда обслуговує експортовані збірники, дані у файлі /etc/exports, точніше написати не обслуговує, а синхронізує з файлом /var/lib/nfs/xtabта видаляє з xtab неіснуючі. exportfs робиться під час запуску демона nfsd з аргументом -r. Утиліта exportfs у режимі ядра 2.6 розмовляє з бісом rpc.mountd через файли каталогу /var/lib/nfs/ і не розмовляє з ядром безпосередньо. Без характеристик видає перелік поточних експортованих файлових систем.

Властивості exportfs:

• [клієнт:ім'я-каталогу] - додати або видалити зазначену файлову систему для зазначеного клієнта)
• -v - виводити більше інформації
• -r - переекспортувати всі збірники (синхронізувати /etc/exports та /var/lib/nfs/xtab)
• -u - видалити зі списку експортованих
• -a - додати або видалити всі файлові системи
• -o - функції через кому (аналогічний опціям застосовуваним в / etc / exports; т.ч. можна змінювати функції вже змонтованих файлових систем)
• -i - не використовувати /etc/exports при додаванні тільки властивості поточного командного рядка
• -f - скинути список експортованих систем у ядрі 2.6;

Клієнт NFS

Перш ніж звернутися до файлу на віддаленій файловій системі клієнт (клієнта) повинен змонтувати їїта отримати від сервера покажчик на неї. Монтування NFSможе проводитися за допомогою команди mountабо за допомогою одного з автоматичних монтувальників, що розплодилися (amd, autofs, automount, supermount, superpupermount). Процес монтування добре продемонстрована вище на ілюстрації.

на клієнтів NFSніяких бісів запускати не потрібно, функції клієнтаробить модуль ядра kernel/fs/nfs/nfs.ko, який використовується при монтуванні віддаленої файлової системи. Експортовані збірники з сервера можуть встановлюватися на клієнта такими способами:

• вручну, за допомогою команди mount
• автоматично при завантаженні, при монтуванні файлових систем, змальованих в /etc/fstab
• автоматом за допомогою біса autofs

Третій метод з autofs в цій статті я розглядати не буду, через його велику інформацію. Можливо, у наступних статтях буде окремий опис.

Монтування файлової системи Network Files System командою mount

Приклад використання команди mount представлений у пості Команди управління блоковими пристроями. Тут я розгляну приклад команди mount для монтування файлової системи NFS:

FILES ~ # mount -t nfs archiv:/archiv-small /archivs/archiv-small FILES ~ # mount -t nfs -o ro archiv:/archiv-big /archivs/archiv-big FILES ~ # mount ..... .. archiv:/archiv-small on /archivs/archiv-small type nfs (rw,addr=10.0.0.6) archiv:/archiv-big on /archivs/archiv-big type nfs (ro,addr=10.0.0.6)

Перша команда монтує експортований каталог /archiv-small на сервері archiv в локальну точку монтування /archivs/archiv-small з налаштуваннями за замовчуванням (тобто для читання та запису).

Хоча команда mountв останніх дистрибутивах вміє обмірковувати який тип файлової системи використовується і без вказівки типу, все ж таки вказувати параметр -t nfs краще. Друга команда монтує експортований каталог /archiv-big на сервері archiv у локальний каталог /archivs/archiv-big з опцією лише для читання (ro). Команда mountбез характеристик наочно показує нам результат монтування. Крім функції лише читання (ro), можливо поставити інші основні функції при монтуванні NFS:

• nosuid - Ця функціязабороняє виконувати setuid програми зі змонтованого каталогу.
• nodev(no device - не пристрій) - Ця функція забороняє використовувати як пристрої символьні та блокові особливі файли.
• lock (nolock)- Дозволяє блокувати NFS (за замовчуванням). nolock вимикає блокування NFS (не запускає демон lockd) і комфортабельна при роботі зі старими серверами, що не підтримують блокування NFS.
• mounthost=ім'я- Ім'я хоста, на якому запущено демон монтування NFS - mountd.
• mountport=n -Порт, використовуваний біс mountd.
• port=n- порт, який використовується для підключення до NFS сервера (за замовчуванням 2049, якщо бес rpc.nfsd не зареєстровано на RPC-сервері). Якщо n=0 (за умовчанням), то NFS посилає запит до portmap на сервері, щоб знайти порт.
• rsize=n(read block size – розмір блоку читання) – Кількість байтів, що читаються за один раз з NFS-сервера. Стандартно – 4096.
• wsize=n(write block size – розмір блоку запису) – Кількість байтів, що записуються за один раз на NFS-сервер. Стандартно – 4096.
• tcpабо udp- Для встановлення NFS використовувати протокол TCP або UDP відповідно.
• bg- При втраті доступу до сервера повторювати проби у фоновому режимі, щоб не перекрити процес завантаження системи.
• fg- При втраті доступу до сервера, повторювати проби у пріоритетному режимі. Цей параметр може заблокувати процес завантаження системи повторення спроб монтування. Тому параметр fg використовується в основному при налагодженні.

Функції кешування атрибутів при монтуванні NFS

Атрибути файлів, що зберігаються в inod ( індексних дескрипторів), такі як час модифікації, обсяг, жорсткі посилання, власник, зазвичай змінюються рідко для звичайних файлів і ще рідше - для каталогів. Багато програм, наприклад ls, звертаються до файлів тільки для читання і не змінюють атрибути файлів або вмісту, але витрачають ресурси системи на дорогі мережеві операції.

Щоб уникнути непотрібних витрат ресурсів, можна кешувати дані атрибути. Ядро використовує час модифікації файлу, щоб знайти застарілий кеш, порівнюючи час модифікації в кеші і час модифікації самого файла. Кеш атрибутів періодично оновлюється відповідно до цими параметрами:

• ac (noac)(attrebute cache - кешування атрибутів) - Дозволяє кешування атрибутів (за замовчуванням). Хоча функція noac уповільнює роботу сервера, вона дозволяє уникнути старіння атрибутів, коли кілька клієнтів активно записують інформацію у спільну ієрархію.
• acdirmax=n(attribute cache directory file maximum - кешування атрибуту максимум для файлу каталогу) - Наї Велика кількістьсекунд, що NFS очікує до оновлення атрибутів каталогу (за замовчуванням Шістдесят сек.)
• acdirmin=n(attribute cache directory file minimum - кешування атрибуту мінімум для файлу каталогу) - Маленька кількість секунд, що NFS очікує до оновлення атрибутів каталогу (за замовчуванням 30 сек.)
• acregmax=n(attribute cache regular file maximum - кешування атрибуту максимум для звичайного файла) - Максимальна кількість секунд, що NFS очікує до оновлення атрибутів звичайного файлу (за замовчуванням Шістдесят сек.)
• acregmin=n(attribute cache regular file minimum- кешування атрибуту мінімум для звичайного файла) - Невелика кількість секунд, яке NFS очікує до оновлення атрибутів звичайного файлу (за замовчуванням Три сек.)
• actimeo=n(attribute cache timeout - тайм кешування атрибутів) - Замінює значення для всіх вишуканих опцій. Якщо actimeo не заданий, вищезазначені значення набувають значення за замовчуванням.

Функції обробки помилок NFS

Наступні функції керують діями NFS за відсутності відповіді від сервера або у разі виникнення помилок вводу/виводу:

• fg (bg)(foreground - передній план, background - задній план) - Створювати проби монтування NFS, що відмовила, на передньому плані/у фоні.
• hard (soft)- виводить на консоль повідомлення "server not responding" при досягненні таймауту та продовжує проби монтування. При цій функції soft- при таймауті повідомляє програмі про помилку введення/виводу, що викликала операцію. (опцію soft радять не використовувати)
• nointr (intr)(no interrupt - не переривати) - Не дозволяє сигналам переривати файлові операціїу жорстко змонтованій ієрархії каталогів при досягненні великого таймууту. intr- дозволяє переривання.
• retrans=n(retransmission value - значення повторної передачі) - Після n малих таймаутів NFS генерує великий таймаут (за замовчуванням 3). Великий тайм-аут припиняє виконання операцій або виводить на консоль повідомлення "server not responding", залежно від вказівки функції hard/soft.
• retry=n(retry value - значення повторної проби) - Кількість хвилин повторень служби NFS операцій монтування, перш ніж здатися (за замовчуванням 10000).
• timeo=n(timeout value - значення таймауту) - Кількість 10-х дещиць секунди очікування службою NFS до повторної передачі у разі RPC або малого таймауту (за замовчуванням 7). Це значення зростає при кожному таймуті до більшого значення Шістдесят секунд або до наступу великого таймууту. У разі зайнятої мережі, повільного сервера або при проходженні запиту через кілька маршрутизаторів або шлюзів, збільшення цього значення може підвищити продуктивність.

Автоматичне монтування NFS при завантаженні (опис файлових систем /etc/fstab)

Опис файлу /etc/fstab я торкався відповідної статті. У цьому прикладі я розгляну кілька прикладів монтування файлових систем NFS з описом опцій:

FILES ~ # cat /etc/fstab | grep nfs archiv:/archiv-small /archivs/archiv-small nfs rw,timeo=4,rsize=16384,wsize=16384 Нуль Нуль nfs-server:/archiv-big /archivs/archiv-big n ,hard,fg Нуль 0

Перший приклад монтує файлову систему /archiv-small з хоста archiv в точку монтування /archivs/archiv-small, тип файлової системи вказаний nfs (завжди необхідно вказувати для даного типу), файлова система монтована з опцією для читання, запису (rw) .

Хост archiv підключений швидкому локальному каналу, тому для зростання продуктивності параметр timeo зменшений і істотно збільшені значення rsize і wsize. Поля для програм dump і fsck задані в нуль, щоб ці програми не використовували файлову систему, примонтовану за NFS.

Другий приклад монтує файлову систему /archiv-big з хоста nfs-server. Т.к. до хоста nfs-server ми підключені по повільному з'єднанню, параметр timeo збільшений до 5 сек (50 10-х дещицею сек), а також жорстко заданий параметр hard, щоб NFS продовжувала перемонтувати файлову систему після великого таймуута, так само заданий параметр fg, щоб при завантаженні системи та недоступності хоста nfs-server не вийшло зависання.

Перш ніж зберігати конфігурації в /etc/fstab, обов'язково спробуйте змонтувати вручну і переконайтеся, що все працює!

Підвищення продуктивності NFS

На продуктивність NFS можуть проводити кілька характеристик, особливо під час роботи через повільні соединения. При роботі з повільними та високонавантаженими з'єднаннями, краще використовувати параметр hard, щоб таймаути не призвели до припинення роботи програм. Але необхідно обмірковувати, якщо змонтувати файлову систему через NFS з параметром hard через fstab, а віддалений хоствиявиться недоступним, то при завантаженні системи відбудеться зависання.

Також, одним із найлегших способів зростання продуктивності NFS - збільшення кількості байтів, що передаються за один раз. Обсяг в Чотири тисячі дев'яносто 6 байт дуже малий для сучасних швидких з'єднань, збільшуючи це значення до Вісім тисяч 100 дев'яносто два і більше можна експериментальним способом визначити найкращу швидкість.

Так само, не варто упускати з уваги і функції тайм-аутів. NFS очікує відповіді на пересилання даних протягом проміжку часу, позначеного у функції timeo, якщо відповіді за цей час не отримано, то робиться повторне пересилання.

Але на завантажених і повільних з'єднаннях цей час може бути менше часу реакції сервера і можливості каналів зв'язку, в результаті чого можуть бути зайві повторні пересилання, що уповільнюють роботу. За умовчанням, timeo дорівнює 0,7 сек (700 мілісекунд). після невідповіді протягом сімсот мс сервер здійснить повторне пересилання і подвоїть час очікування до 1,4 сек., збільшення timeo триватиме до більшого значення в Шістдесят сек. Далі в залежності від параметра hard/soft відбудеться будь-яка дія (див. вище).

Підібрати найкращий timeo для певного значення пакета, що передається (значень rsize/wsize), можна за допомогою команди ping:

FILES ~ # ping -s 30 дві тисячі сімсот шістдесят вісім archiv PING archiv.DOMAIN.local (10.0.0.6) 32768(32796) bytes of data. 30 дві тисячі сімсот 70 6 bytes від archiv.domain.local (10.0.0.6): icmp_req=1 ttl=64 time=0.931 ms 30 дві тисячі сімсот 70 6 bytes from archiv.domain.local (10.0.0.0.6. 2 ttl=64 time=0.958 ms 30 дві тисячі сімсот 70 6 bytes від archiv.domain.local (10.0.0.6): icmp_req=3 ttl=64 time=1.03 ms 30 дві тисячі сімсот 70 6 bytesdo. (10.0.0.6): icmp_req=4 ttl=64 time=1.00 ms 30 дві тисячі сімсот 70 6 bytes from archiv.domain.local (10.0.0.6): icmp_req=5 ttl=64 time=1.08 ms ^ archiv.DOMAIN.local ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 0.931/1.002/1.083/0.061 ms

Як бачимо, при відправленні пакета розміром 30 дві тисячі сімсот шістдесят вісім (32Kb) час його подорожі від клієнта до сервера і назад плаває у районі Один мілісекунди. Якщо даний час зашкалюватиме за Двісті мс, то варто задуматися про підвищення значення timeo, щоб воно перевищувало значення обміну в три-чотири рази. Відповідно, даний тесткраще робити під час сильного завантаження мережі

Запуск NFS та налаштування Firewall

Нотатка скопіпсована з блогу http://bog.pp.ru/work/NFS.html, за що йому величезне спасибі!

Запуск сервера NFS, монтування, блокування, квотування та статусу з "правильними" портами (для мережного екрана)

• краще попередньо розмонтувати всі ресурси на клієнтах
• зупинити та заборонити запуск rpcidmapd, якщо не планується впровадження NFSv4: chkconfig --level Триста 40 5 rpcidmapd off service rpcidmapd stop
• якщо потрібно, то дозволити запуск сервісів portmap, nfs і nfslock: chkconfig --levels Триста 40 5 portmap/rpcbind on chkconfig --levels Триста 40 5 nfs on chkconfig --levels Триста 40 5 nfslock on
• якщо потрібно, то зупинити сервіси nfslock і nfs, запустити portmap/rpcbind, вивантажити модулі service nfslock stop service nfs stop service portmap start # service rpcbind start umount /proc/fs/nfsd service rpcidmapd stops його необхідно запустити rmmod nfs rmmod nfs_acl rmmod lockd
• відкрити порти в iptables
  • для RPC: UDP/111, TCP/111
  • для NFS: UDP/2049, TCP/2049
  • для rpc.statd: UDP/4000, TCP/4000
  • для lockd: UDP/4001, TCP/4001
  • для mountd: UDP/4002, TCP/4002
  • для rpc.rquota: UDP/4003, TCP/4003
• для сервера rpc.nfsd додати до /etc/sysconfig/nfs рядок RPCNFSDARGS="--port 2049"
• для сервера монтування додати до /etc/sysconfig/nfs рядок MOUNTD_PORT=4002
• для функції rpc.rquota для нових версій необхідно додати /etc/sysconfig/nfs рядок RQUOTAD_PORT=4003
• для функції rpc.rquota необхідно для старих версій (все-таки, необхідно мати пакет quota 3.08 або свіже) додати /etc/services rquotad 4003/tcp rquotad 4003/udp
• перевірить адекватність /etc/exports
• запустити сервіси rpc.nfsd, mountd та rpc.rquota (заодно запускаються rpcsvcgssd та rpc.idmapd, якщо не забули їх видалити) service nfsd start або в нових версіях service nfs start
• для сервера блокування для нових систем додати /etc/sysconfig/nfs рядки LOCKD_TCPPORT=4001 LOCKD_UDPPORT=4001
• для сервера блокування для старих систем додати безпосередньо до /etc/modprobe[.conf]: options lockd nlm_udpport=4001 nlm_tcpport=4001
• прив'язати сервер статусу rpc.statd до порту Чотири тисячі (для старих систем /etc/init.d/nfslock запускати rpc.statd з ключем -p 4000) STATD_PORT=4000
• запустити сервіси lockd та rpc.statd service nfslock start
• переконатися, що це порти прив'язалися нормально з допомогою "lsof -i -n -P" і "netstat -a -n" (частина портів використовується модулями ядра, які lsof не бачить)
• якщо перед "перебудовою" сервером користувалися клієнти та їх не вдалося розмонтувати, то доведеться перезапустити на клієнтах сервіси автоматичного монтування (am-utils, autofs)

Приклад конфігурації NFS сервера та клієнта

Конфігурація сервера

Якщо ви бажаєте зробити ваш розділений NFS каталог відкритим і з правом запису, ви можете використовувати опцію all_squash у композиції з опціями anonuid та anongid. Наприклад, щоб встановити права користувача "nobody" у групі "nobody", ви можете зробити таке:

ARCHIV ~ # cat /etc/exports # Доступ на читання та запис для клієнта на 192.168.0.100, з доступом rw для користувача Дев'яносто дев'ять з gid Дев'яносто дев'ять /files 99)) # Доступ на читання та запис для клієнта на 192.168.0.100, з доступом rw для користувача Дев'яносто дев'ять з gid Дев'яносто дев'ять /files

Це також означає, що якщо ви бажаєте дозволити доступ до зазначеної директорії, nobody.nobody має бути власником розділеної директорії:

# chown -R nobody.nobody /files

Конфігурація клієнта

На клієнті необхідно примонтувати віддалений каталог зручним способом, наприклад командою mount:

FILES ~ # mount -t nfs archiv:/files /archivs/files

Резюме

Фух... Статтю завершено. На даний момент ми вивчили що таке Network File Systemта з чим її їдять, у наступній статті спробую зробити HOWTO з автентифікацією Kerberos. Сподіваюся, матеріал вийшов дохідливим і потрібним.

Буду радий Вашим доповненням та коментарям!

NFS HOWTO, nfs.sourceforge, man nfs? man mount, man exports

RFC Одна тисяча дев'яносто чотири - NFSv1, v2
RFC Одна тисяча вісімсот тринадцять - NFSv3
RFC Три тисячі 500 30 - NFSv4
RFC 5 тисяч 600 шістдесят один - NFSv4.1
NFS HOWTO
nfs.sourceforge.net
man mount
man exports

Зручне рішення для доступу до розподіленої файлової системи

Файлова система – це необхідність. Ми працюємо на комп'ютерах, що надають доступ до принтерів, камер, баз даних, віддаленим датчикам, телескопам, компіляторам та мобільним телефонам. Ці пристрої мають мало спільного - зокрема, багато хто з них стали реальністю вже після того, як Інтернет став повсюдним явищем (наприклад, електронні фотокамери та мобільні пристрої, що виконують функції маленьких комп'ютерів). Однак усім їм потрібна файлова система для зберігання та захищеного доступу до інформації.

Зазвичай нам не важливо, як дані, додатки, що їх використовують, та інтерфейси, що їх представляють нам, зберігаються в самих комп'ютерах. Більшість користувачів хотіли б розглядати (і виправдано) файлову систему як стіну, що відокремлює їх від голого заліза, що зберігає біти та байти. Тому стеки протоколів, що з'єднують файлові системи, зазвичай залишаються чорними скриньками більшість користувачів і, насправді, програмістів. Проте зрештою, організація мережевої взаємодіївсіх цих пристроїв зводиться до дозволу обміну даними між файловими системами.

Мережеві файлові системи та інші священнодії

Багато в чому обмін даними є не більше ніж копіюванням інформації на великі відстані. Мережеві протоколи були єдиним засобом, завдяки якому став можливий загальний обмін даними. Зрештою, кожна комп'ютерна система повинна перетворювати датаграми на щось зрозуміле для операційної системи на іншому кінці. TCP - це дуже ефективний протокол передачі, але не оптимізований для забезпечення швидкого доступу до файлів або для віддаленого керування прикладним програмним забезпеченням.

Розподілені обчислення проти мережевих

Традиційні мережеві протоколи небагато можуть запропонувати організації обчислень, розподілених між комп'ютерами і, тим більше, між мережами. Тільки безрозсудні програмісти покладалися на протокол передачі і оптичні кабелі у створенні паралельних обчислень. Зазвичай ми покладаємося на послідовну модель, у якій після встановлення з'єднання починають працювати протоколи канального рівня, що виконують досить складну процедуру вітання між мережними картами. Паралельні обчислення та розподілені файлові системи більше не залежать від IP або Ethernet. В даний час ми можемо їх просто не брати до уваги, говорячи про продуктивність. Проте проблеми захисту – це інша справа.

Однією з ланок головоломки є спосіб організації доступу до файлів у комп'ютерній системі. Зараз для системи, що здійснює доступ до файлів, є несуттєвим, чи доступні необхідні файли на одному комп'ютері, або вони розташовані з якихось причин на кількох комп'ютерах. В даний час семантика файлової системи та структури даних файлової системи є двома дуже різними темами. Семантика файлової системи Plan 9 або розподіленої файлової системи AFS-стилю (Andrew File System) приховує спосіб організації файлів або спосіб відображення файлової системи на апаратне та мережеве забезпечення. NFS не обов'язково приховує спосіб зберігання файлів та каталогів на віддалених файлових системах, але вона також не розкриває дійсний апаратний спосіб зберігання файлових систем, каталогів та файлів.

NFS: Вирішення UNIX-проблеми

Доступ до розподіленої файлової системи, проте, потребує дещо більше пари команд, що дозволяють користувачам монтувати каталог, який розташований на іншому комп'ютері в мережі. Sun Microsystems зіткнулася з цією проблемою кілька років тому, коли починала розповсюджувати щось назване Remote Procedure Calls(RPCs), та NFS.

Основною проблемою, яку намагалися вирішити в Sun, був спосіб підключення кількох UNIX-комп'ютерів для організації єдиного розподіленого робочого середовища без необхідності переписувати семантику файлової системи UNIX і додавати занадто велику кількість структур даних, специфічних для розподілених файлових систем - цілісність кожної системи мала бути збережена одночасно надаючи користувачам можливість роботи з каталогом на іншому комп'ютері без виникнення небажаних затримок або обмежень у їх робочому процесі.

Звичайно, NFS робить більше, ніж надання доступу до текстових файлів. Ви можете також розподіляти по NFS програми, що "запускаються". Процедури системи захисту служать для захисту мережі від шкідливого втручання файлів, що виконуються. Але як це відбувається?

NFS – це RPC

NFS зазвичай визначається як RPC-додаток, що вимагає наявності TCP для NFS-сервера, а також TCP, або іншого не перевантажує мережу протоколу для NFS-клієнта. Організація Internet Engineering Task Force (IETF) опублікувала Request for Comments (RFC) для RPC RFC 1832. Інший життєво важливий для функціонування NFS-реалізації стандарт описує формати даних, використовувані NFS; він був опублікований в RFC 1831 як документ "External Data Representation" (XDR).

Інші RFC мають справу із захистом та алгоритмами шифрування, які використовуються під час обміну інформацією для аутентифікації під час NFS-сесій, але ми спочатку зупинимося на базових механізмах. Одним із протоколів, які нас цікавлять, є протокол Mount, описаний у Додатку 1 RFC 1813

Цей RFC описує, які протоколи забезпечують функціонування NFS, але не описується, як NFS функціонує в теперішній час. Ви вже дізналися дещо важливе, а саме - протоколи NFS задокументовані у вигляді IETF-стандартів. Після того, як остання версія NFS застрягла на цифрі 3, RPC-протоколи не розвивалися далі інформаційної фази RFC і сприймалися в основному як не виходять за межі інтересів (імовірно) величезної інженерної робочої групи Sun Microsystems та патентованих різновидів UNIX. З 1985 року Sun випустила кілька версій NFS, яка на кілька років передбачила більшість сучасних різновидів файлових систем. Sun Microsystems передала контроль над NFS організації IETF в 1998 році, і більшість роботи над NSF версії 4 (NFSv4) проводилася під егідою IETF.

Тобто, працюючи сьогодні з RPC та NFS, ви працюєте з версією, яка відображає інтереси компаній та груп, що не мають відношення до Sun. Однак багато інженерів Sun зберігають глибокий інтерес до розробки NFS.

NFS версії 3

NFS у втіленні у вигляді версії 3 (NFSv3) не зберігає свій стан (не є stateful), а NFSv4 зберігає. Цей фундаментальний вираз сьогодні навряд чи когось дивує, хоча світ TCP/IP, на якому побудована NFS, здебільшого не зберігає свого стану (stateless) - факт, який допомагає компаніям, що виробляють програмне забезпечення для аналізу трафіку та системи захисту, відчувати себе досить добре.

Протокол NFSv3 повинен був покладатися на кілька додаткових протоколів для прозорого монтування каталогів на віддалених комп'ютерах, щоб не залежати від механізмів файлових систем, що використовуються на них. NFS не завжди процвітала в цьому. Гарний приклад- протокол Mount викликав початковий ідентифікатор файлу, тоді як протокол Network Lock Manager займався блокуванням файлу. Обидві операції потребували поточному стані, яке NFSv3 не надавав. Отже, були складні взаємодії між рівнями протоколів, які не відображали аналогічні механізми потоків даних. Крім того, якщо додати той факт, що створення файлу та каталогу в Microsoft® Windows® здійснюється зовсім не так, як у UNIX, ситуація ще більше ускладниться.

Протокол NFSv3 повинен був використовувати порти для надання деяких його допоміжних протоколів; при цьому виходить досить складна картина портів, рівнів протоколів і супутніх питань безпеки. Сьогодні від такої моделі функціонування відмовилися, і всі операції, які раніше виконували реалізацію допоміжних протоколів через індивідуальні порти, керуються протоколом NFSv4 через один добре відомий порт.

Протокол NFSv3 був також готовий для роботи з файловими системами, що підтримують Unicode - перевагу, яка до кінця 1990-х років залишалася певною мірою суто теоретичною. Він добре відповідав семантиці файлової системи UNIX і став причиною створення конкуруючих реалізацій файлових систем, таких як AFS і Samba. Не дивно, що підтримка Windows була бідною, але файлові сервери Samba забезпечували загальний доступ до файлів для систем UNIX і Windows.

NFS версії 4

Протокол NFSv4 є, як ми зазначили, протоколом, що зберігає свій стан. Така поведінка уможливила кілька радикальних змін. Ми вже згадували, що повинні викликатися допоміжні протоколи, оскільки процеси рівня користувача були усунені. Замість них всі операції з відкриття файлу і багато RPC-дзвінків були реалізовані у вигляді операцій файлової системи рівня ядра.

Усі NFS-версії визначали кожну одиницю роботи у поняттях операцій RPC-клієнта та сервера. Кожен NFSv3-запит вимагав досить значної кількості RPC-дзвінків та викликів операцій відкриття портів для видачі результату. Версія 4 спростила це, ввівши поняття так званої складовий(compound) операції, до якої належать велика кількість операцій над об'єктами файлової системи. Прямим ефектом, зрозуміло, стало значно менше RPC-дзвінків і менший обсяг даних, які потрібно передавати по мережі, навіть при тому, що кожен RPC-дзвінок ніс, по суті, більше даних, виконуючи значно більший обсяг роботи. Приблизно було підраховано, що RPC-дзвінки в NFSv3 вимагали в п'ять разів більшу кількість клієнт-серверних взаємодій порівняно зі складовими RPC-процедурами.

RPC, насправді, більше не має такої важливості і, по суті, служить оболонкою над кількома операціями, інкапсульованими в NFSv4-стеку. Також ця зміна зробила стек протоколу набагато менш залежним від семантики файлової системи, що використовується. Але це не означає, що операції файлової системи інших операційних систем були проігноровані: наприклад, для спільного використання Windows-ресурсів потрібне збереження стану під час відкриття ресурсу. Збереження стану як полегшує аналіз трафіку, але за реалізації лише на рівні семантики файлової системи робить операції файлової системи значно доступнішими контролю. Виклики відкриття ресурсів із збереженням стану дозволяють клієнтам кешувати файлові дані та стан - те, що інакше відбувалося б на сервері. У реальному житті (у якому Windows-клієнти поширені повсюдно) організація прозорої та уніфікованої роботи NFS-серверів з поділюваними Windows-ресурсами стоїть витраченого вами часу на налаштування NFS-конфігурації.

Використання NFS

Установка NFS, загалом, аналогічна до установки Samba. На стороні сервера ви визначаєте файлові системи або каталоги для експорту або спільного використання; клієнтська сторона встановлює ці каталоги. Після встановлення віддаленим клієнтом NFS-каталогу цей каталог стає доступним так само, як будь-який інший каталог локальної файлової системи. Налаштування NFS на сервері – це простий процес. Як мінімум, ви повинні створити або відредагувати файл /etc/exports і запустити демон NFS. Для налаштування більш захищеної служби NFS ви повинні також відредагувати файли /etc/hosts.allow та /etc/hosts.deny. NFS-клієнт вимагає виконання лише команди mount. Додаткова інформація та параметри описані в оперативній документації з Linux® (man page).

NFS-сервер

Записи у файлі / etc / exports мають зрозумілий формат. Для організації спільного доступу до файлової системи змініть файл /etc/exports та опишіть файлову систему (з параметрами) у такому загальному форматі:

каталог (або файлова система) client1 (option1, option2) client2 (option1, option2)

Загальні параметри

Для налаштування вашої NFS-реалізації є кілька загальних параметрів. До них відносяться:

• secure:Цей параметр (за замовчуванням) використовує для підключення NFS доступний порт TCP/IP, менший за 1024. Вказівка ​​взахист забороняє це.
• rw:Цей параметр дозволяє NFS-клієнтам доступ до читання/запису. Стандартний доступ - тільки для читання.
• async:Цей параметр може підвищити продуктивність, але може також викликати втрату даних при перезапуску NFS-сервера без попередньої процедури зупинення NFS-демону. Налаштування за промовчанням - sync .
• no_wdelay:Цей параметр вимикає затримку під час запису. Якщо встановлено async , NFS ігнорує цей параметр.
• nohide:Якщо ви монтуєте один каталог поверх іншого, старий каталог зазвичай ховається або виглядає порожнім. Щоб заборонити таку поведінку, дозвольте параметр hide.
• no_subtree_check:Цей параметр вимикає контроль підкаталогів, який виконується для деяких перевірок системою захисту, які ви, можливо, не бажаєте ігнорувати. Параметр за замовчуванням – дозволити контроль підкаталогів.
• no_auth_nlm:Цей параметр при значенні insecure_locks вказує NFS-демону не проводити аутентифікацію під час запитів на блокування. Стандартний параметр - auth_nlm або secure_locks .
• mp (mountpoint=path) :При явному оголошенні цього параметра NSF вимагає монтування каталогу, що експортується.
• fsid=num:Цей параметр зазвичай використовується для організації системи відновлення після збою NFS. Якщо ви хочете реалізувати відновлення після збою NFS, зверніться до документації NFS.

Відображення користувачів

Через відображення користувачів у NFS ви можете ототожнити псевдокористувача або реального користувача та групи з користувачем, що працює з томом NFS. Користувач NFS має права користувача або групи, які дозволяє відображати. Використання єдиного (generic) користувача та групи для NFS-томів забезпечує рівень захисту та гнучкість без значних зусиль з адміністрування.

При використанні файлів на NFS-монтованій файловій системі користувальницький доступ зазвичай "пригнічується" (squashed). Це означає, що користувач звертається до файлів як анонімний користувач, який має доступ до цих файлів лише читання. Ця поведінка особливо важлива для користувача root. Однак, існують ситуації, коли ви хочете, щоб користувач звертався до файлів на віддаленій системі як root або інший певний користувач. NFS дозволяє вказати користувача (за ідентифікаційним номером користувача (UID) та ідентифікаційним номером групи (GID)) для доступу до віддалених файлів, і ви можете заборонити нормальну поведінку "придушення" за умовчанням.

До параметрів відображення користувачів належать:

• root_squash:Цей параметр не дозволяє користувачеві root звертатися до змонтованого NFS.
• no_root_squash:Цей параметр дозволяє користувачеві root звертатися до змонтованого NFS тому.
• all_squash:Цей параметр корисний для NFS-томів з відкритим доступом, пригнічує всі UID та GID та використовує лише обліковий запис анонімного користувача. Стандартна установка - no_all_squash .
• anonuid та anongid:Ці параметри змінюють UID та GID анонімного користувача на вказаний обліковий запис.

У лістингу 1 наведено приклади записів /etc/exports.

Лістинг 1. Приклади записів /etc/exports

/opt/files 192.168.0.* /opt/files 192.168.0.120 /opt/files 192.168.0.125(rw, all_squash, anonuid=210, anongid=100) /opt/files *(ro,

Перший запис експортує каталог /opt/files для всіх хостів мережі 192.168.0. Наступний запис експортує /opt/files для одного хоста: 192.168.0.120. Третій запис вказує хост 192.168.0.125 і надає доступ до читання/запису до файлів з правами користувача, що має user id=210 і group id=100 . Остання запис використовується для загальнодоступного каталогу і дозволяє доступ лише за читанням і лише під обліком анонімного користувача.

NFS-клієнт

Застереження

Після використання NFS для монтування віддаленої файлової системи, вона також буде частиною будь-якої операції створення спільної резервної копіїсистеми, яку ви виконуєте на клієнтському комп'ютері. Ця поведінка може призвести до потенційно шкідливих результатів, якщо ви не виключите змонтовані каталоги при резервуванні.

Для використання NFS як клієнта на клієнтському комп'ютері повинен виконуватися rpc.statd і portmap. Ви можете виконати команду ps -ef для перевірки присутності цих двох демонів. Якщо вони працюють (як і повинні), ви можете монтувати каталог, що експортується сервером, за допомогою наступної спільної команди:

mount server:directory local mount point

Взагалі, при монтуванні файлової системи ви повинні працювати як користувач root. На віддаленому комп'ютері ви можете використовувати наступну команду (припущення, що NFS-сервер має IP-адресу 192.168.0.100):

mount 192.168.0.100:/opt/files /mnt

Ваш дистрибутив системи може вимагати вказівки типу файлової системи під час її монтування. Якщо це так, використовуйте команду:

mount -t nfs 192.168.0.100:/opt/files /mnt

Видалений каталог повинен монтуватися без жодних проблем, якщо ви коректно налаштували сервер. Тепер виконайте команду cd для переходу до каталогу /mnt, а потім команду ls для перегляду файлів. Для того, щоб зробити таке монтування постійним, ви повинні змінити файл /etc/fstab і створити запис, аналогічний наступному:

192.168.0.100:/opt/files /mnt nfs rw 0 0

Примітка:Додаткову інформацію про записи /etc/fstab наведено в оперативній довідці fstab.

Критика NFS

Критика сприяє покращенню

Критика, пов'язана із захищеністю NFS, була причиною багатьох покращень у NSFv4. Творці нової версії провели реальні заходи щодо посилення захищеності клієнт-серверних взаємодій. Фактично вони вирішили реалізувати абсолютно нову модель системи захисту.

Для розуміння моделі системи захисту ви повинні ознайомитись з інтерфейсом прикладного програмування Generic Security Services (GSS-API)версії 2, редакції 1. GSS-API повністю описаний RFC 2743, який, на жаль, є одним з найбільш складних для розуміння RFC-документів.

На наш досвід роботи з NFSv4 ми знаємо, що не дуже легко зробити мережну файлову систему незалежною від операційної системи. Але ще важче зробити незалежними від операційної системи та мережевих протоколіввсі галузі системи захисту. Нам потрібно і те, й інше, оскільки NFS має бути здатна обробляти досить велику кількість користувацьких операційі робити це без зв'язку зі специфікою взаємодії мережного протоколу.

З'єднання між NFS-клієнтами та серверами захищаються за допомогою так званої (досить поверхнево) системи захисту strong RPC. NFSv4 використовує стандарт Open Network Computing Remote Procedure Call (ONCRPC), визначений RFC 1831. Система захисту повинна була бути посилена, тому замість простої аутентифікації (відомої як AUTH_SYS) як обов'язкова частина протоколу NFSv4 було визначено та реалізовано різновид заснованої на GSS-API системи захисту, відомий під назвою RPCSEC_GSS. До найважливіших доступних у NFSv4 механізмів захисту відносяться Kerberos версії 5 та LIPKEY.

Якщо Kerberos має обмеження при використанні в Інтернеті, то у LIPKEY є приємна перевага - працюючи як Secure Sockets Layer (SSL), він запитує у користувачів їх імена та паролі, уникаючи в той же час TCP-залежності від SSL - залежності, яку NFSv4 не поділяє. Ви можете налаштувати NFS на реалізацію різновидів системи захисту, якщо RPCSEC_GSS не потрібно. Попередні версії NFS не мали такої можливості і, отже, не могли забезпечити якісний захист, цілісність даних, вимоги до автентифікації або типи шифрування.

Протокол NFSv3 піддався суттєвій критиці у сфері захищеності. Якщо NFSv3-сервери працювали через TCP, було цілком реально запускати NFSv3-мережі через Інтернет. На жаль, потрібно було також відкривати кілька портів, що призводило до появи кількох добре розрекламованих дірок у системі захисту. Зробивши порт 2049 обов'язковим для NFS, стало можливим використання NFSv4 з брандмауерами (firewall) без необхідності приділяти надто велику увагу тому, які порти прослуховували інші протоколи, наприклад протокол Mount. Таким чином, виключення протоколу Mount мало кілька позитивних ефектів:

• Обов'язкові механізми суворої автентифікації: NFSv4 зробив механізми суворої автентифікації обов'язковими. Різновиди Kerberos досить поширені. Також має підтримуватись Lower Infrastructure Public Key Mechanism (LIPKEY). NFSv3 ніколи не підтримував щось більше, ніж стандартне UNIX-шифрування для автентифікації доступу – це породжувало основні проблеми захисту у великих мережах.
• Обов'язкові схеми списків контролю доступу (access control list - ACL) у стилі Microsoft Windows NT: Хоча NFSv3 дозволяв реалізувати суворе шифрування для аутентифікації, він не використовував схеми ACL-доступу стилі Windows NT. Списки ACLу стилі Portable Operating System Interface (POSIX) іноді реалізовувалися, але ніколи не були загальноприйнятими. NFSv4 зробив ACL-схеми у стилі Windows NT обов'язковими.
• Договірні механізми та стилі аутентифікації: NFSv4 надав можливість домовлятися про механізми та стилі автентифікації. У NSFv3 було неможливо зробити щось більше, ніж ручне визначеннявикористовуваний стиль шифрування. Системний адміністраторповинен був потім узгоджувати протоколи шифрування та захисту.

Чи досі NFS поза конкуренцією?

NFSv4 замінює NFSv3 на більшості систем UNIX та Linux. Як мережна файлова система NSFv4 має мало конкурентів. Життєздатним конкурентом могла б вважатися Common Internet File System (CIFS)/Server Message Block (SMB), виходячи з того, що вона є у всіх різновидах Windows і (нині) в Linux. AFS ніколи не мала великого комерційного впливу; в ній надавалося особливого значення елементам розподілених файлових систем, які полегшували міграцію та реплікацію даних.

Готові до використання Linux-версії NFS були випущені після досягнення ядром версії 2.2, але однією з загальних невдач версій ядра Linux було те, що Linux прийняв NFSv3 досить пізно. Фактично пройшло багато часу до того, коли Linux почав повністю підтримувати NSFv3. З появою NSFv4 цей недолік був швидко усунений і повну підтримку NSFv4 реалізували не тільки в Solaris, AIX та FreeBSD.

NFS вважається в даний час зрілою технологією, яка має досить велику перевагу: вона захищена та зручна - більшість користувачів вважали зручним використовувати одну захищену реєстрацію для доступу до мережі та для використання її можливостей, навіть коли файли та програми розташовані на різних системах. Хоча це може виглядати як недолік у порівнянні з розподіленими файловими системами, що приховують структури систем від користувачів, не забувайте про те, що багато програм використовують файли, що знаходяться на різних операційних системах і, отже, на різних комп'ютерах. NFS полегшує роботу з різними операційними системами без необхідності занадто турбуватися про семантику файлових систем та характеристики їхньої продуктивності.

Мережева файлова система 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 не набагато складніше за підключення. Якщо у вас залишилися питання, пишіть у коментарях!

Схожі записи: