Формати назв машин¶

Клієнти NFS можуть бути вказані у різноманітний спосіб:

єдиний хост

Це найпоширеніший формат. Ви можете вказати хост або через скорочене ім'я, зрозуміле розв'язувачу імен, або через повне доменне ім'я або IP-адресу.

мережна група

Мережна група (NIS netgroup) може бути вказаною як @group. Перевірка належності до мережної групи перевіряється по хостовій частині назв членів кожної групи. Ті, що містять порожню хостову частину назви або риску (-) замість неї, ігноруються.

байдужі знаки

Назви машин можна вказувати з використанням байдужих знаків * й ?. Це допомагає зробити файл exports більш компактним; наприклад, *.cs.foo.edu співпадатиме зі всіма хостами у домені cs.foo.edu. Байдужі знаки також співпадають з крапками у назвах хостів, тож вказаний зразок збігатиметься також зі всіма хостами у будь-якому піддомені cs.foo.edu.

мережі IP

Ви можете також експортувати каталоги файлової системи одночасно всім хостам на (під-) мережі IP. Цього можна досягти, якщо вказати адресу IP і мережну маску одночасно як address/netmask, де netmask вказується як "десяткова через крапку" нотація, або як неперервна довжина маски (наприклад, або `/255.255.252.0', або `/22', які додаються до базової мережної адреси і які позначають ідентичні підмережі з 10-и бітовим діапазоном хостів). Байдужі знаки, як правило, не працюють з IP-адресами, хіба завдяки випадковості, коли зворотній пошук DNS зазнає невдачі.

Безпека завдяки RPCSEC_GSS¶

Щоб обмежити доступ до експортованого пункту, використайте захист через rpcsec_gss (RFC2203) через вказування спеціального ланцюжка "gss/krb5" у якості клієнта. На жаль, немає можливості одночасного використання rpcsec_gss і IP-адрес клієнтів.

Загальні опції¶

exportfs розуміє наступні опції експортування:

secure

Ця опція вимагає щоб запити здійснювались на інтернет-порті зі значенням меншим за IPPORT_RESERVED (1024). Ця опція ввімкнена за замовчуванням, щоб її вимкнути потрібно вказати insecure.

rw

Дозволяє як запити на читання, так і запис ємності NFS. За замовчуванням будь-які, що привносять зміни до файлової системи, заборонені. Останнє можна вказати явно ключовим словом ro.

async

Ця опція дозволяє серверу порушувати протокол NFS і відповідати на запити до того як будь-які зміни, спричинені цим запитом, були збережені на стабільному носієві (наприклад жорсткому диску).

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

У попередніх релізах nfs-utils аж до 1.0.0 включно, ця опція була стандартною. У цій версії і наступних, sync вживається за замовчуванням, і async повинне бути вказаним явно, якщо саме таке поводження є бажаним. Для того, щоб повідомити системних адміністраторів про цю зміну поводження у різних версіях серверу, 'exportfs' видає попередження у випадку не вказаних sync або async опцій.

no_wdelay

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

nohide

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

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

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

Опція nohide, на сьогодення, підтримується тільки для експортування для єдиного хосту, вона не працює надійно у випадку мережевих груп, підмереж або вказівки байдужих знаків у якості адрес.

Ця опція може бути корисною у деяких ситуаціях, але нею варто вживати з обережністю і тільки після підтвердження того, що система клієнта належно справляється таким приєднанням.

Цю опцію можна явно скасувати, вказавши hide.

no_subtree_check

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

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

Для того щоб здійснити таку перевірку, сервер повинен включити деяку інформацію про місцезнаходження файлу у так званому "маніпуляторі файлу" (filehandle), яка надається клієнтові. Це може спричинити проблеми, під час доступу до файлів, чия назва помінялась, клієнт маючи їх відкритими (хоча у багатьох простих випадках, це працює).

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

Як загальна підказка, файлова система домашнього каталогу, де відбувається багато змін назв файлів, повинна експортуватися з вимкненою перевіркою структури. Файлові системи, які в основному тільки для читання і на яких назви файлів рідко змінюються (/usr, /var) і які можуть включати додаткові підкаталоги (з файлами, що належать root), напевне повинні експортуватися з перевіркою деревовидної структури.

Стандартне поводження, коли перевірка структури має місце, можна вказати явно опцією subtree_check.

insecure_locks

no_auth_nlm

Ці дві опції, які являються синонімами, вказують NFS-серверу не вимагати аутентифікації запитів на блокування (тобто запитів, що використовують протокол NLM, Network Lock Manager). Звично, NFS-сервер вимагатиме щоб запит на блокування містив посвідчення користувача, що має доступ на читання файлу. З вищевказаними прапорцями, не перевіряється право на доступ.

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

Стандартне поводження, при якому вимагається аутентифікації для запитів до NML, може бути вказаним явно також двома опціями-синонімами: auth_nlm і secure_locks.

mountpoint=шлях

mp

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

Якщо шлях вказано (тобто mountpoint=шлях або mp=шлях), тоді саме цей шлях буде пунктом монтування, який буде експортовано пунктом експортування.

fsid=номер

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

Деякі файлові системи Лінукса не приєднуються на блокових пристроях, тож експортування цих файлових систем через NFS вимагає штучного створення номеру fsid (хоча іноді цього також недостатньо).

Значення 0 має спеціальний зміст, коли використовується з NFSv4 (четвертої версії). NFSv4 послуговується концептом кореня цілої експортованої файлової системи. Саме пункт експортування з fsid=0 буде цим коренем.

Перетворення користувацьких ID

Керування доступом до файлів на серверній машині у nfsd основується на UID і GID, що постачаються з кожним запитом NFS RPC. Користувачі очікують прозорого поводження, при якому доступ до віддаленого диску нічим не відрізнявся би від доступу до файлів і каталогів на локальному диску. Це вимагає того, щоб ті самі UID і GID використовувались на клієнтській і серверній машині. Це не завжди відповідає істині і не завжди є можливим або бажаним.

Дуже часто небажано, щоб користувач root на клієнтській машині, також розглядався як root на NFS-сервері. У таких випадках, UID під номером 0 буде перетворено на відмінний ідентифікаційний номер, так званий анонімний UID користувача nobody. Таке поводження серверу являється стандартним; це називається "розчавити користувача root" (root squash). Стандартне поводження можна пересилити опцією no_root_squash.

Типово, exportfs вибирає UID і GID, що дорівнюють

-2

(тобто 65534) для "розчавленого" доступу. Ці значення також можуть бути пересиленими опціями anonuid і anongid. І, накінець, ви можете перетворити всі користувацькі запити до анонімного UID опцією all_squash.

Ось повний список перетворень ідентифікації користувачів:

root_squash

Перетворює всі запити з UID/GID 0 до анонімного UID/GID. Зауважте, що це не стосується всіх інших UID, що можуть бути також дещо небезпечними, якщо надати їм доступ, скажімо такого користувача як bin .

no_root_squash

Вимкне перетворення UID користувача root. Ця опція придатна хіба для бездискових клієнтів.

all_squash

Перетворює всі UID/GID до анонімного. Корисна для експортованих через NFS публічних каталогів FTP, каталогів новин і.т.п. Протилежною є no_all_squash, що використовується за замовчуванням.

anonuid і anongid

Ці опції відверто встановлюють UID і GID анонімного облікового запису. Ця опція цікава, головним чином, для клієнтів NFS на персональних комп'ютерах, де ви б хотіли щоб всі запити здавались ніби надходять від того самого користувача. Як приклад, гляньте на пункт експортування /home/joe у прикладі з наступного розділу, який перетворює всі запити до UID 150 (який повинен відповідати UID користувача joe).