НАЗВА

exports - експортування файлових систем NFS (для NFS основаних на ядрі)

СТИСЛИЙ ОГЛЯД

/etc/exports

ОПИС

Файл /etc/exports служить списком керування доступом до файлових систем, які можуть експортуватися клієнтам NFS. Він використовується ?exports(8) для надання інформації ?mountd(8), також для файлового серверу NFS, основаному на ядрі - ?nfsd(8)

Формат файлу подібний до того, що використовується у файлі exports від SunOS. Кожний рядок містить пункт експортування і, розділений пробілами, список клієнтів, яким дозволено приєднання файлових у цьому пункті. Одразу за кожним переліченим клієнтом може слідувати привнесений у дужки розділений комами список опцій експортування для даного клієнту. Пробіли між назвами клієнтів і їхніми опціями заборонені.

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

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

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

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

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

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

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

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

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

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

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

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

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

вказати явно ключовим словом ro.

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

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.

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

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

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

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

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

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

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

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).

ПРИКЛАДИ

# приклад файлу /etc/exports
/            master(rw) trusty(rw,no_root_squash)
/projects    proj*.local.domain(rw)
/usr         *.local.domain(ro) @trusted(rw)
/home/joe    pc001(rw,all_squash,anonuid=150,anongid=100)
/pub         (ro,insecure,all_squash)

У першому прикладі експортується вся файлова система машинам master і trusty. На додаток до дозволу на запис, перетворення UID користувача root вимкнене на trusty. Другий і третій приклади демонструють використання байдужих символів з назвами хостів і використання мережних груп (@trusted). Четвертий рядок є прикладом анонімізації всіх запитів, яку ми розглянули у попередньому розділі. П'ятий рядок експортує публічний каталог FTP кожному хостові в Інтернеті, перетворюючи кожний запит на анонімний (користувач nobody). Опція insecure у цьому прикладі, дозволяє також доступ клієнтів з реалізаціями NFS, що не використовують резервований для NFS порт (2049).

ФАЙЛИ

/etc/exports

Переклав Віталій Цибуляк vt@uatech.atspace.com