Мережева файлова система (NFS 4)

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

Для усунення цих недоліків протокол NFS 4 був розроблений повністю заново: підтримується управління правами через списки контролю доступу (АСЕ), а також безпечна автентифікація доступу із застосуванням Kerberos та SPKM-3. NFS автоматично вирішує завдання, пов'язані з блокуванням і підключенням пристроїв, так що для цього не потрібно окремих RPC-демонів. NFS 4 вірно відображає символи Unicode, що містяться в іменах файлів. Весь обмін інформацією здійснюється через TCP 2049, завдяки чому спрощується конфігурація брандмауера (без UDP і динамічних портів).

На жаль, у NFS 4 також є свої недоліки: конфігурація протоколу складна, а клієнта, що вільно розповсюджується, для Windows поки немає. Протягом довгого часу NFS також вважався недоробленим та нестабільним, але ці початкові складнощі вже подолано.

У цій статті буде розглядатися серверна та клієнтська конфігурація системи аутентифікації, тобто описується, як найшвидше розпочати роботу з NFS 4. На практиці часто потрібно застосовувати NFS 4 разом з LDAP та Kerberos — як правило, це стосується мереж з великою кількістю користувачів. Такий ускладнений варіант конфігурації я не зможу описати тут, оскільки цього не дозволяють розміри книги.

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

У сучасних версіях Linux за замовчуванням підтримується NFS 4. Але вам обов'язково слід переконатися, що комп'ютерзапущено службу rpc.idmapd. Вона співвідносить ім'я користувача NFS та UID/GID. Чи ця служба запускається і як саме запускається, залежить від дистрибутива.

Конфігурація rpc.idmapd виконується у файлі /etc/idmap.conf. Як правило, його можна залишити в тому вигляді, в якому він був при постачанні.

Конфігурація каталогів, які повинні експортуватися за NFS, побудована зовсім інакше, ніж у NFS 3: всі каталоги повинні бути підпорядковані одному кореневому каталогу, який відіграє роль файлової псевдосистеми. Цю концепцію простіше зрозуміти з прикладу. Припустимо, нам потрібно експортувати каталоги /data/audio та /data/pictures/photos. Для цього створюємо три нові каталоги, а як кореневий використовуємо /nfsexport (зрозуміло, назва цього каталогу може бути довільною).

Щоб надалі цей процес проходив автоматично, додайте /etc/fstab (на сервері) два наступні рядки:

Закінчивши підготовчі роботи, ви можете змінити /etc/exports. Цей файл відповідає за роботу NFS 4, причому синтаксис практично аналогічний NFS 3. Додається лише два параметри.

Кореневий каталог NFS 4 позначається параметром fsid=0. У системі може бути лише один кореневий каталог (ще раз зазначу: у NFS 4 неможливо експортувати каталоги, що знаходяться за межами кореневого каталогу). Параметр crossmnt також вказується лише для кореневого каталогу. Завдяки цьому параметру при підключенні підкаталогів їхній вміст залишається видимим для клієнтів і тоді, коли кореневий каталог на клієнтському комп'ютері залишається не підключеним. Замість параметра crossmnt кореневого каталогу можна вказувати для будь-яких каталогів параметр nohide - він допомагає досягти такого ж результату.

Як зазвичай, exportfs -a гарантує, що вже діючий NFS-сервер враховуватиме нові записи.

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

В якості альтернативи можна імпортувати лише підкаталог: