Использование NFS в Linux среде  
  Содержание  


Настоящие материалы являются авторскими, права автора защищены Законами РФ и международными соглашениями. Для использования настоящих материалов вам необходимо ознакомиться и полностью принять лицензионное соглашение. В случае, если вы не принимаете настоящее лицензионное соглашение полностью, вы не имеете права пользоваться настоящими материалами


В UNIX среде заманчиво организовать файловый сервер средствами самого UNIX, а именно через NFS. Однако существует ряд моментов, снижавших привлекательность такого решения для администратора. Если говорить о версиях NFS до выхода NFSv4, т.е. NFSv3, то сразу можно отметить ряд отрицательных моментов: использование RPC для организации обмена, усложняющее понимание и затрудняющее работу через серевые фильтры, а также, что наиболее важно - низкая безопасность, основывающаяся на доверии клиентским узлам. То есть при монтировании раздела NFS с правами на модификацию сервер доверял информации клиентского узла о имени пользователя. Если вы разворачивали клиентский узел с любым разрешённым на сервере IP и создавали пользователя с нужным вам именем, то вы могли подмонтировать серверный раздел и модифицировать его с правами созданного пользователя

С появлением NFSv4 появилась возможность обойти эти узкие места, однако это требовало тщательного конфигурирования и увязки с другими инфраструктурными службами, в частности с сервером аутентификации Kerberos. В гетерогенной среде практически всегда проще использовать для организации файлового сервера программный продукт Samba, и на долю NFS остаются редкие задачи технологического расшаривания папок между серверами и обеспечение относительно редко встречающихся UNIX конфигураций. Об одной из таких конфигураций и пойдёт речь с настоящей статье

Условия задачи - развернуть небольшую управляемую сеть на UNIX с возможностью пользователей одинаково удобно работать с каждого клиентского места. В качестве серверов сети используется среда виртуализации под KVM, в качестве операционной системы сервера виртуализации и виртуальных серверов выбрана OC Scientific Linux 6.1. В качестве клиентских рабочих машин используется Debian stable (squeeze) и Ubuntu разных версий

Для организации управляемой сетевой инфраструктуры в виртуальной среде развёрнуты сервера - сетевой (DNS, DHCP, NTP), инфраструктурный (Kerberos MIT, LDAP, rsyslog), медийный с домашними каталогами и общими файловыми разделами, коммуникационный с (Exim, Squid) и ряд других. Для удобства управления и использования на инфраструктурном сервере развёрнуты службы единого каталога пользователей в части аутентификации (Kerberos) и хранения учётной информации пользователей и групп (openldap). Конфигурация каталога максимально типизирована и вынесена в DNS сервер для автоматического получения её клиентами из одной точки, сетевая конфигурация клиентов также управляется из одной точки - сервер DHCP - привязкой конфигурации каждого известного клиента к его MAC адресу сетевой карты. Также настроена синхронизация времени всех серверов и клиентов с выделенным NTP сервером сети, все сервера и клиенты "керберизированы" и "лдапизированы", организован вынос журнальной информации на сервер журналирования rsyslog. Кроме того организован серсис сетевого развёртывания ОС на клиентских компьютерах, сконфигурировано резервирование виртуальных серверов выделением вторых серверов, а также резервирование конфигураций серверов и клиентов на сервере резервирования. Отказоустойчивость дисковой подсистемы реализована созданием софтверного зеркала, а также выносными бэкапами. Дальнейшие пути повышения отказоустойчивости для данной задачи существуют, но признаны излишними. Такова базовая архитектура сети

Такова базовая архитектура сети, и описание "как детально технически" развернуть большую часть описанных сервисов выложено и публично доступно в моих различных тематических статьях, размещённых на этом же сайте. С такими вводными мы подходим к организации единой для сети файловой системы, что позволит любому пользователю получать на любом клиенте доступ к своему домашнему каталогу, а значит и своим настройкам, сохранённым данным и т.п., а также к расположенным в одном и том же привычном месте общим файловым ресурсам, при этом конечно должно обеспечиваться разграничение прав. Всё это, вкупе с основанной на Kerberos системой единого входа и сервером каталога LDAP, а также ряда вспомогательных сервисов позволит говорить о создании единой управляемой и резервируемой IT инфраструктуры

Для корректной работы конфигурируемый NFS сервер использует ряд дополнительных сервисов и демонов. Так как нам необходимо получить полновесную сетевую файловую систему в разделением прав и исключить ущербный механизм доверия клиентских хостам, используем NFSv4 с авторизацией через Kerberos. Kerberos обеспечивает авторизацию принципала по имени, тогда как операционная система оперирует в первую очередь цифровым идентификатором (ID) пользователя, связывая его с именем. В частности вы можете иметь несколько пользователей с разнвми именами, но одинаковым идентификатором, и права этих пользователей будут одинаковы. Поэтому для целей синхронизации имени пользователя и идентификатора на горизонте операционной системы мы применяем хранение учётных данных пользователей и групп, в т.ч. ID, в едином каталоге LDAP, и извлекаем эти данные посредством библиотеки nss. А на горизонте NFS для целей синхронизации имени и ID используются сервисы rpc.idmap, rpc.srvgssd и rpc.gssd, которые требуют настройки

Для начала каждый сервер и клиент необходимо креберизировать, а также добавить на сервер и в keytab файл каждого узла принципала nfs/FQDN_хоста@REALM. О том, что значат эти термины, можно посмотреть у меня в статье о развёртывании инфраструктуры Kerberos http://www.ourorbits.org/itview/articles/in_kerberos.shtml. На момент добавления узел должен быть "керберизирован" и "лдапизирован", в частности сетевые пользователи должны иметь возможность корректно входить на узел (серверный или клиентский) с выдачей сообщения о недоступности домашнего каталога

Конфигурирование сервера сводится к установке соответствующих программных пакетов, и редактированию ряда конфигурационных файлов. Для Scientific Linux v.6.1 необходимо сконфигурировать следующие файлы:

  • /etc/sysconfig/nfs в основном добавляем журнализацию для этапа конфигурирования, строки RPCIDMAPDARGS=" -vvv ", SECURE_NFS="yes", RPCGSSDARGS=" -vvv -rrr -k полный_путь_к_вашему_лунефи_файлу", RPCSVCGSSDARGS=" -rrr -vvv -iii "
  • /etc/idmapd.conf редактируем строки Verbosity = 1, Domain = имя_вашего_DNS_домена, Local-Realms = имя_вашего_Kerberos_REALM, Method = nsswitch
  • /etc/gssapi_mech.conf для нашей конфигурации этот файл не трогаем
  • /etc/exportfs - в этом файле собственно и прописываются экспортируемые файловые системы. Удобно создать отдельный каталог и смонтировать в него в режиме привязки требуемые точки файловой системы. Также важно определить опции аспользования kerberos аутентификации

Ниже приведён пример файла /etc/exports:

/nfsexport               gss/krb5(sync,rw,fsid=0,insecure,no_subtree_check,anonuid=65534,anongid=65534)
/nfsexport/transit       gss/krb5(sync,rw,nohide,insecure,no_subtree_check,anonuid=65534,anongid=65534)
#...
/nfsexport/documentation gss/krb5(sync,ro,fsid=3,nohide,insecure,no_subtree_check,anonuid=65534,anongid=65534)
/nfsexport/home          gss/krb5(sync,ro,fsid=4,nohide,insecure,no_subtree_check,anonuid=65534,anongid=65534)
#...
/nfsexport/repositaries  gss/krb5(sync,ro,fsid=6,nohide,insecure,no_subtree_check,anonuid=65534,anongid=65534)

Клиенты использую основанные на Debian дистрибутивы Linux, и расположение конфигурационных файлов отличается от RedHat-based Scientific Linux. На клиентах, применительно к конфигурированию непосредственно NFS, необходимо редактировать следующие конфигурационные файлы

  • /etc/idmapd.conf редактируем строки Verbosity = 1, Domain = имя_вашего_DNS_домена. Строки Local-Realms в этом файле по умолчанию нет ни в Debiab, ни в UBUNTU, и если не указать имя_вашего_Kerberos_REALM, используется приведённое к верхнему регистру имя_вашего_DNS_домена
  • /etc/default/nfs-common редактируем строки NEED_IDMAPD=yes и NEED_GSSD=yes
  • /etc/fstab непосредственно описывает подключаемые файловые системы, например:
    FQDN_NFS_сервера:/ /mnt/mediaserver nfs4 sec=krb5,nosuid,nodev,noexec,noauto,users  0 0
    

В общем то это было бы всё, если бы не несколько подводных камней. К сожалению NFS4 не поддерживает строгую криптографию Kerberos, и потому на сервер и во все клиенты необходимо включить в раздел [libdefaults] файла /etc/krb5.conf строку allow_weak_crypto = true, и перезапустить KDC. Без указания этой опции в журнал записываются ошибки вида (https://bugs.launchpad.net/ubuntu/+bug/575895):

Unspecified GSS failure. Minor code may provide more information - (minor)
 No supported encryption types (config file error?)"

Кроме того, входящая в дистрибутив Scientific Linux v.6.1 версия nfs-utils имеет баг, требующий обновления пакета, например до версии nfs-utils-1.2.3-15.el6.x86_64.rpm. Без обновления сервер NFS не отрабатывает корректно (http://bugs.centos.org/view.php?id=5161, https://bugzilla.redhat.com/show_bug.cgi?id=720479), выдавая ошибки вида:

ERROR: GSS-API: error in gss_export_lucid_sec_context(): GSS_S_NO_CONTEXT
 (No context has been established) и
ERROR: failed serializing krb5 context for kernel

После конфигурирования и тестирования можно подавить излишнюю журнализацию в конфигурационных файлаи и убрать опцию noauto для монтирования при перезагрузке, или же настроить автомонтирование

(C) Белонин С.С., декабрь 2011 г., Москва

(даты последующих модификаций не фиксируются)


 
     
   
   
    Нравится      

(C) Белонин С.С., 2000-2018. Дата последней модификации страницы:2018-01-09 13:25:37