Эти материалы являются объектом авторского права и защищены законами РФ и международными соглашениями о защите авторских прав. Перед использованием материалов вы обязаны принять условия лицензионного договора на использование этих материалов, или же вы не имеете права использовать настоящие материалы

Авторская площадка "Наши орбиты" состоит из ряда тематических подразделов, являющихся моими лабораторными дневниками, содержащими записи за разное, иногда продолжительно отличающееся, время. Эти материалы призваны рассказать о прошедшем опыте, они никого ни к чему не призывают и совершенно не обязательно могут быть применимы кем-то ещё. Это только лишь истории о прошлом

В 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 г., Москва