Небольшое предисловие к статье.
Заказчик выставил требование организовать доступ по CIFS (SMB) к некоторым NFS-экспортам, которые лежат на NetApp. Звучит вроде бы несложно: нужно создать CIFS-шару на уже экспортированном qtree. Позже было выставлено требование, что нужно гранулярно управлять доступом на эти шары. Опять-таки задача выглядит решаемой: это можно контролировать и с NetApp и через оснастку Shared Folders (share permissions). Затем выяснилось, что нужно варьировать доступ к различным подпапкам на CIFS-шаре. Это уже оказалось нетривиальной задачей. Так как нужно было настроить списки контроля доступа (ACL) и для CIFS и для NFS к одним и тем же данным.
На первый взгляд, можно воспользоваться классическими правами доступа в Linux. У каждой папки и файла есть атрибуты владельца, группы владельца и others (все остальные). Ниже приведен пример классических прав доступа в Linux.
Но что делать, если нужно более гранулярно контролировать доступ? POSIX ACLs? Они не поддерживаются NetApp. В итоге единственным решением оказались NFSv4 ACLs.
В этой статье предлагаем описание того, как транслировать NFSv4 ACLs для Windows-пользователей. Будем проводить нашу настройку пошагово. Стиль будет максимально сжатый и емкий. Я не буду останавливаться на каждом пункте подробно, к тому же не буду приводить детального листинга всех команд. Итак, приступим.
Предполагается, что в данной инфраструктуре существует сервер LDAP, через который происходит авторизация и аутентификация пользователей. Поэтому маппинг не используется и соответственно файл usermap.cfg не правится. Также не нужно вносить изменений в файлы passwd и group — все пользователи и группы берутся из LDAP. Ниже приведены параметры необходимые для нормальной работы сцепки:
Их необходимо выполнить на целевом vFiler. Отмечу, что существуют различные вариации этих настроек. И в вашей конкретной инфраструктуре это может не взлететь. В нашем случае мы цеплялись к AD DC с FSMO ролью Global Catalog. Проверка работоспособности сцепки на NetApp возможно провести командами getXXbyYY и wcc. Эти команды можно выполнить только в advanced mode.
Примеры корректной работы команды getXXbyYY:
Если эта команда не возвращает подобный вывод, значит что-то настроено не так.
Для того, чтобы корректно работало разрешение имен и групп, в Unix-средах нужно сделать правки в файле /etc/nsswitch.conf. Выставляем в начало ldap для строк passwd и group:
Есть небольшая ремарка относительно корректной работы групп в случае использования LDAP. Внутри групп, которые будут иметь доступ к Linux и Windows средам одновременно, должен быть заполнен атрибут ‘memberUid’. Важно: он должен быть заполнен в нижнем регистре. В атрибут необходимо прописать пользователей этой группы. Ниже выделено поле memberuid в атрибутах группы, которая должна быть доступна в средах Linux и Windows.
Мы хотим транслировать NFSv4 permissions (читай UNIX) в Windows среду, то есть они будут основными списками контроля доступа. Поэтому мы будем использовать для наших томов/qtree UNIX-style permissions.
Создаем том/qtree, создаем на нем экспорт NFS. В файле /etc/exports видим следующую картину:
Делаем настройку следующих опций:
Следующие настройки необходимо выполнить на конечном Linux сервере, на который и монтируется наш экспорт с NetApp.
Монтируем экспорт со следующими опциями:
nfs acl,defaults,intr,hard,bg,tcp,auto,rw 0 0
Затем уже внутри нашего экспорта назначаем ACLы согласно нашим потребностям. NFSv4 ACLs чуть помощнее чем POSIX ACLs и довольно близки к CIFS ACLs. Существует 2 команды для работы со списками: nfs4_getfacl и nfs4_setfacl. Нетрудно догадаться, что одной командой мы считываем имеющиеся списки доступа, а второй назначаем. Ниже пример настройки NFSv4 ACLS на папку test:
Где А – allow, D – deny.
При внесении изменений воспользуемся командой:
Тогда конфиг откроется в текстовом редакторе.
Как мы видим существует множество возможностей контролировать доступ для каждого файла и папки.
Теперь необходимо настроить доступы. После этого проверяем, что на Linux нужные права для нужных пользователей.
Для этого настраиваем сервисы CIFS через cifs setup.
После этого создаем CIFS шару на файлере на тот же том/qtree, на котором у нас лежит экспорт.
Права при создании шары оставляем EVERYONE/FULL CONTROL. Это нужно для того, чтобы не было лишних ограничений на уровне шары.
Права на уровне файловой системы уже регулируются при помощи инструмента NFSv4 ACLs.
Это было финальной настройкой. Теперь подключаемся теми же юзерами, которыми подключались в Linux, и проверяем доступ. У NetApp есть старая утилита, которая показывает Linux permissions в средах Windows. Называется она SecureShare. Можно также воспользоваться для проверки и ею. Ниже скриншот дополнительной вкладки после установки утилиты SecureShare.
Заказчик выставил требование организовать доступ по CIFS (SMB) к некоторым NFS-экспортам, которые лежат на NetApp. Звучит вроде бы несложно: нужно создать CIFS-шару на уже экспортированном qtree. Позже было выставлено требование, что нужно гранулярно управлять доступом на эти шары. Опять-таки задача выглядит решаемой: это можно контролировать и с NetApp и через оснастку Shared Folders (share permissions). Затем выяснилось, что нужно варьировать доступ к различным подпапкам на CIFS-шаре. Это уже оказалось нетривиальной задачей. Так как нужно было настроить списки контроля доступа (ACL) и для CIFS и для NFS к одним и тем же данным.
На первый взгляд, можно воспользоваться классическими правами доступа в Linux. У каждой папки и файла есть атрибуты владельца, группы владельца и others (все остальные). Ниже приведен пример классических прав доступа в Linux.
>$ ls -lrt
drwxr-xr-x. 2 root root 4096 May 8 15:47 nfsv4_test
Но что делать, если нужно более гранулярно контролировать доступ? POSIX ACLs? Они не поддерживаются NetApp. В итоге единственным решением оказались NFSv4 ACLs.
В этой статье предлагаем описание того, как транслировать NFSv4 ACLs для Windows-пользователей. Будем проводить нашу настройку пошагово. Стиль будет максимально сжатый и емкий. Я не буду останавливаться на каждом пункте подробно, к тому же не буду приводить детального листинга всех команд. Итак, приступим.
Привязка NetApp к LDAP
Предполагается, что в данной инфраструктуре существует сервер LDAP, через который происходит авторизация и аутентификация пользователей. Поэтому маппинг не используется и соответственно файл usermap.cfg не правится. Также не нужно вносить изменений в файлы passwd и group — все пользователи и группы берутся из LDAP. Ниже приведены параметры необходимые для нормальной работы сцепки:
ldap.ADdomain ##здесь указывается домен, к которому будем цепляться
ldap.base DC=com
ldap.enable on
ldap.fast_timeout.enable on
ldap.minimum_bind_level simple
ldap.name ##учетка, с которой будет проходить запрос в базу
ldap.nssmap.attribute.homeDirectory unixHomeDirectory
ldap.nssmap.attribute.uid sAMAccountName
ldap.nssmap.objectClass.posixAccount User
ldap.nssmap.objectClass.posixGroup Group
ldap.port 3268
ldap.retry_delay 10
ldap.servers ##адреса домен-контроллеров
ldap.usermap.attribute.unixaccount uid
ldap.usermap.attribute.windowsaccount sAMAccountName
Их необходимо выполнить на целевом vFiler. Отмечу, что существуют различные вариации этих настроек. И в вашей конкретной инфраструктуре это может не взлететь. В нашем случае мы цеплялись к AD DC с FSMO ролью Global Catalog. Проверка работоспособности сцепки на NetApp возможно провести командами getXXbyYY и wcc. Эти команды можно выполнить только в advanced mode.
Примеры корректной работы команды getXXbyYY:
FILER0*> vfiler run VFILER03 getXXbyYY getpwbyname_r ivanov
===== VFILER03
pw_name = ivanov
pw_passwd = {{******}}
pw_uid = 10000, pw_gid = 10000
pw_gecos = Ivanov, Ivan
pw_dir = /home/ivanov
pw_shell = /bin/bash
Если эта команда не возвращает подобный вывод, значит что-то настроено не так.
Для того, чтобы корректно работало разрешение имен и групп, в Unix-средах нужно сделать правки в файле /etc/nsswitch.conf. Выставляем в начало ldap для строк passwd и group:
passwd: ldap nis files
group: ldap nis files
Есть небольшая ремарка относительно корректной работы групп в случае использования LDAP. Внутри групп, которые будут иметь доступ к Linux и Windows средам одновременно, должен быть заполнен атрибут ‘memberUid’. Важно: он должен быть заполнен в нижнем регистре. В атрибут необходимо прописать пользователей этой группы. Ниже выделено поле memberuid в атрибутах группы, которая должна быть доступна в средах Linux и Windows.
Конфигурация NFSv4 на NetApp.
Мы хотим транслировать NFSv4 permissions (читай UNIX) в Windows среду, то есть они будут основными списками контроля доступа. Поэтому мы будем использовать для наших томов/qtree UNIX-style permissions.
Создаем том/qtree, создаем на нем экспорт NFS. В файле /etc/exports видим следующую картину:
/vol/xxx_VFILER03_nfs_vol00/ACL_test -sec=sys,rw,root=192.168.0.1,nosuid
Делаем настройку следующих опций:
nfs.v4.acl.enable on
nfs.v4.enable on
nfs.v4.id.allow_numerics on
Конфигурация NFSv4 ACLs на Linux
Следующие настройки необходимо выполнить на конечном Linux сервере, на который и монтируется наш экспорт с NetApp.
Монтируем экспорт со следующими опциями:
nfs acl,defaults,intr,hard,bg,tcp,auto,rw 0 0
Затем уже внутри нашего экспорта назначаем ACLы согласно нашим потребностям. NFSv4 ACLs чуть помощнее чем POSIX ACLs и довольно близки к CIFS ACLs. Существует 2 команды для работы со списками: nfs4_getfacl и nfs4_setfacl. Нетрудно догадаться, что одной командой мы считываем имеющиеся списки доступа, а второй назначаем. Ниже пример настройки NFSv4 ACLS на папку test:
>$ nfs4_getfacl test
A::OWNER@:rwatTnNcCy
A::alice@nfsdomain.org:rxtncy
A::bob@nfsdomain.org:rwadtTnNcCy
A:g:GROUP@:rtncy
D:g:GROUP@:waxTC
A::EVERYONE@:rtncy
D::EVERYONE@:waxTC
Где А – allow, D – deny.
При внесении изменений воспользуемся командой:
>$nfs4_setfacl –e test
Тогда конфиг откроется в текстовом редакторе.
Как мы видим существует множество возможностей контролировать доступ для каждого файла и папки.
Теперь необходимо настроить доступы. После этого проверяем, что на Linux нужные права для нужных пользователей.
Создание CIFS шары на NetApp
Для этого настраиваем сервисы CIFS через cifs setup.
После этого создаем CIFS шару на файлере на тот же том/qtree, на котором у нас лежит экспорт.
FILER0> vfiler run VFILER03 cifs shares -add ACL_test /vol/xxx_ VFILER03 _nfs_vol00/ACL_test
Права при создании шары оставляем EVERYONE/FULL CONTROL. Это нужно для того, чтобы не было лишних ограничений на уровне шары.
FILER0> vfiler run VFILER03 cifs shares
ACL_test /vol/xxx_ VFILER03 _nfs_vol00/ACL_test
everyone / Full Control
Права на уровне файловой системы уже регулируются при помощи инструмента NFSv4 ACLs.
Это было финальной настройкой. Теперь подключаемся теми же юзерами, которыми подключались в Linux, и проверяем доступ. У NetApp есть старая утилита, которая показывает Linux permissions в средах Windows. Называется она SecureShare. Можно также воспользоваться для проверки и ею. Ниже скриншот дополнительной вкладки после установки утилиты SecureShare.