Бөлісу құралы:

Настройка домена идентификатора NFSv4.1 для Azure NetApp Files

  • Мақала

NFSv4 представляет концепцию домена проверки подлинности идентификатора. Azure NetApp Files использует значение defaultv4iddomain.com записи в качестве домена проверки подлинности, а клиенты NFS используют собственную конфигурацию для проверки подлинности пользователей, которые хотят получить доступ к файлам на этих томах. По умолчанию клиенты NFS будут использовать DNS-имя домена в качестве домена идентификатора NFSv4. Этот параметр можно переопределить с помощью файла конфигурации NFSv4 с именем idmapd.conf.

Если параметры домена проверки подлинности в клиенте NFS и Azure NetApp Files не совпадают, доступ к файлам может быть запрещен, так как сопоставление пользователей и групп NFSv4 может завершиться ошибкой. Когда это происходит, пользователи и группы, которые не соответствуют правильно, будут хватить пользователя и группу, настроенную в idmapd.conf файле (как правило, никто:99) и событие будет зарегистрировано на клиенте.

В этой статье объясняется поведение по умолчанию сопоставления пользователей и групп и настройка NFS-клиентов для правильной проверки подлинности и разрешения доступа. 

Поведение по умолчанию при сопоставлении пользователей/групп

Сопоставление корневых пользователей может проиллюстрировать, что происходит, если между клиентами Azure NetApp Files и NFS возникает несоответствие. Процесс установки приложения часто требует использования корневого пользователя. Azure NetApp Files можно настроить для предоставления доступа root.

В следующем примере списка каталогов пользователь root подключает том на клиенте Linux, который использует конфигурацию по умолчанию для домена проверки подлинности идентификатора, который отличается от конфигурации defaultv4iddomain.comпо умолчанию localdomain Azure NetApp Files.

Снимок экрана: выходные данные каталога файлов.

В списке файлов в каталоге file1 отображается сопоставление nobodyс , когда он должен принадлежать корневому пользователю.

Существует два способа настройки домена проверки подлинности на обеих сторонах: Azure NetApp Files в качестве сервера NFS и Linux в качестве клиентов NFS:

  1. Централизованное управление пользователями. Если вы уже используете централизованное управление пользователями, например службы домен Active Directory (AD DS), вы можете настроить свои клиенты Linux для использования LDAP и задать домен, настроенный в AD DS в качестве домена проверки подлинности. На стороне сервера необходимо включить доменную службу AD для Azure NetApp Files и создать тома с поддержкой LDAP. Тома с поддержкой LDAP автоматически используют домен, настроенный в AD DS в качестве домена проверки подлинности.

    Дополнительные сведения об этом процессе см. в разделе "Включение проверки подлинности LDAP служб домен Active Directory (AD DS) для томов NFS.

  2. Вручную настройте клиент Linux: если вы не используете централизованное управление пользователями для клиентов Linux, вы можете вручную настроить клиенты Linux для соответствия домену проверки подлинности Azure NetApp Files для томов, не включенных LDAP.

В этом разделе мы рассмотрим настройку клиента Linux и изменение домена проверки подлинности Azure NetApp Files для всех томов, не поддерживающих ПРОТОКОЛ LDAP.

Настройка домена идентификатора NFSv4.1 в Azure NetApp Files

Вы можете указать нужный домен идентификатора NFSv4.1 для всех томов, отличных от LDAP, с помощью портал Azure. Этот параметр применяется ко всем томам, отличным от LDAP, во всех учетных записях NetApp в одной подписке и регионе. Это не влияет на тома с поддержкой LDAP в одной подписке и регионе NetApp.

регистрация компонента

Azure NetApp Files поддерживает возможность задать домен идентификатора NFSv4.1 для всех томов, отличных от LDAP в подписке, с помощью портал Azure. Эта функция в настоящее время доступна для предварительного ознакомления. Если эта функция используется впервые, ее необходимо сначала зарегистрировать. После регистрации эта функция будет включена и начнет работать в фоновом режиме.

  1. регистрация компонента

    Register-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFNFSV4IDDomain

  2. Проверка состояния регистрации функции.

    Примечание.

    RegistrationState может находиться в состоянии Registering до 60 минут, прежде чем изменится на Registered. Подождите, пока состояние не станет Registered, прежде чем продолжить.

    Get-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFNFSV4IDDomain

Вы также можете использовать команды Azure CLI az feature register и az feature show, чтобы зарегистрировать эту функцию и отобразить состояние регистрации.

Шаги

  1. В подписке Azure NetApp Files выберите домен идентификатора NFSv4.1.

  2. Выберите Настроить.

  3. Чтобы использовать домен defaultv4iddomain.comпо умолчанию, выберите поле рядом с доменом идентификатора NFSv4 по умолчанию. Чтобы использовать другой домен, снимите текстовое поле и укажите имя домена идентификатора NFSv4.1.

    Снимок экрана: поле для задания домена NFSv4.

  4. Выберите Сохранить.

Настройка домена идентификатора NFSv4.1 в клиентах NFS

  1. Отредактируйте файл /etc/idmapd.conf на клиенте NFS.
    Раскомментируйте строку #Domain (то есть удалите # из строки) и измените значение localdomain следующим образом:

    • Если том не включен для LDAP, используйте домен defaultv4iddomain.com по умолчанию, указав Domain = defaultv4iddomain.comили укажите домен идентификатора NFSv4.1, как настроено в Azure NetApp Files.
    • Если том включен для LDAP, задайте Domain домен, настроенный в подключении Active Directory к учетной записи NetApp. Например, если contoso.com это настроенный домен в учетной записи NetApp, установите его Domain = contoso.com.

    В следующих примерах показана начальная конфигурация /etc/idmapd.conf перед изменениями:

    [General]
Verbosity = O 
Pipefs—Directory = /run/rpc_pipefs 
# set your own domain here, if it differs from FQDN minus hostname 
# Domain = localdomain 

[Mapping] 
Nobody-User = nobody 
Nobody-Group = nogroup

    В следующем примере показана обновленная конфигурация томов, отличных от LDAP NFSv4.1 для домена defaultv4iddomain.comпо умолчанию:

    [General]
Verbosity = O 
Pipefs—Directory = /run/rpc_pipefs 
# set your own domain here, if it differs from FQDN minus hostname 
Domain = defaultv4iddomain.com 

[Mapping] 
Nobody-User = nobody 
Nobody-Group = nogroup

    В следующем примере показана обновленная конфигурация томов NFSv4.1 с поддержкой LDAP. В этом примере contoso.com настроен домен в учетной записи NetApp:

    [General]
Verbosity = O 
Pipefs—Directory = /run/rpc_pipefs 
# set your own domain here, if it differs from FQDN minus hostname 
Domain = contoso.com

[Mapping] 
Nobody-User = nobody 
Nobody-Group = nogroup

  2. Размонтируйте все подключенные в данный момент тома NFS.

  3. Обновите файл /etc/idmapd.conf.

  4. Очистка ключа NFS idmapper (nfsidmap -c).

  5. При необходимости смонтируйте тома NFS.

    См. раздел "Подключение тома для виртуальных машин Windows или Linux".

В следующем примере показано изменение пользователя/группы в результате:

Снимок экрана, на котором показан пример изменения пользователя/группы в результате.

Как показывает пример, пользователь/группа теперь изменились с nobody на root.

Поведение других пользователей и групп ,не являющихся пользователями и группами

Azure NetApp Files поддерживает локальных пользователей и группы (созданные локально на клиенте NFS и представленные идентификаторами пользователей и групп) и соответствующие права владения и разрешения, связанные с файлами или папками в томах NFSv4.1. Однако служба не решает автоматически сопоставление локальных пользователей и групп между клиентами NFS. Пользователи и группы, созданные на одном узле, могут или не существовать на другом клиенте NFS (или существуют с различными идентификаторами пользователей и групп) и поэтому не сопоставляются правильно, как описано в приведенном ниже примере.

В следующем примере Host1 имеется три учетные записи пользователя (testuser01, testuser02, ): testuser03

Снимок экрана, который показывает, что у Host1 есть три существующих тестовых учетных записи пользователя.

В Host2ней нет соответствующих учетных записей пользователей, но один и тот же том подключен на обоих узлах:

Итоговая конфигурация для NFSv4.1

Чтобы устранить эту проблему, создайте отсутствующие учетные записи на клиенте NFS или настройте клиенты NFS для использования сервера LDAP, который Azure NetApp Files использует для централизованно управляемых удостоверений UNIX.

Следующие шаги