Configurar um cliente NFS para o Azure NetApp Files

Artigo
06/01/2023

A configuração de cliente NFS descrita neste artigo faz parte da configuração da criptografia do Kerberos do NFSv 4.1 ou da criação de um volume de protocolo duplo ou do NFSv 3/NFSv 4.1 com o LDAP. Uma ampla variedade de distribuições do Linux está disponível para uso com o Azure NetApp Files. Este artigo descreve as configurações de dois dos ambientes mais comumente usados: RHEL 8 e Ubuntu 18.04.

Requisitos e considerações

Independentemente do tipo de Linux usado, as configurações a seguir são necessárias:

Configure um cliente NTP para evitar problemas com distorção de tempo.
Configure entradas DNS do cliente Linux para a resolução de nomes.
Essa configuração deve incluir o registro "A" (encaminhar) e o registro de PTR (reverso).
Para ingresso no domínio, crie uma conta de computador para o cliente Linux no Active Directory de destino, criado durante o comando de junção de realm.

Observação

A variável $SERVICEACCOUNT usada nos comandos abaixo deve ser uma conta de usuário com permissões ou delegação para criar uma conta de computador na unidade organizacional de destino.

Configuração do RHEL 8

Esta seção descreve as configurações do RHEL necessárias para a criptografia Kerberos do NFSv 4.1 e para o protocolo duplo.

Os exemplos nesta seção usam o nome de domínio e o endereço IP a seguir:

Nome de domínio: contoso.com
IP privado: 10.6.1.4

Configuração do RHEL 8 ao usar a criptografia Kerberos do NFSv 4.1

Configure /etc/resolv.conf com o servidor DNS apropriado.

Por exemplo:

[root@reddoc cbs]# cat /etc/resolv.conf
search contoso.com
nameserver 10.6.1.4(private IP)
Adicione o registro de cliente NFS no servidor DNS para a zona de pesquisa inversa e de encaminhamento de DNS.
Para verificar o DNS, use os seguintes comandos no cliente NFS:

# nslookup [hostname/FQDN of NFS client(s)]
# nslookup [IP address of NFS client(s)]
Instalar pacotes:

yum update
sudo yum -y install realmd sssd adcli samba-common krb5-workstation chrony nfs-utils
Configure o cliente NTP.

O RHEL 8 usa chrony por padrão.

Ingressar em um domínio do Active Directory:

sudo realm join $DOMAIN.NAME -U $SERVICEACCOUNT --computer-ou="OU=$YOUROU"

Por exemplo:

sudo realm join CONTOSO.COM -U ad_admin --computer-ou="CN=Computers"

Certifique-se de que default_realm esteja definido para o realm fornecido em /etc/krb5.conf. Caso contrário, adicione-o na seção [libdefaults] do arquivo, conforme mostrado no exemplo a seguir:

[libdefaults]
    default_realm = CONTOSO.COM
    default_tkt_enctypes = aes256-cts-hmac-sha1-96
    default_tgs_enctypes = aes256-cts-hmac-sha1-96
    permitted_enctypes = aes256-cts-hmac-sha1-96
[realms]
    CONTOSO.COM = {
        kdc = dc01.contoso.com
        admin_server = dc01.contoso.com
        master_kdc = dc01.contoso.com
        default_domain = contoso.com
    }
[domain_realm]
    .contoso.com = CONTOSO.COM
    contoso.com = CONTOSO.COM
[logging]
    kdc = SYSLOG:INFO
    admin_server = FILE=/var/kadm5.log

Reiniciar todos os serviços NFS:

systemctl start nfs-*
systemctl restart rpc-gssd.service

A reinicialização impede a condição de erro “mount.nfs: an incorrect mount option was specified” durante a montagem do Kerberos.
Execute o comando kinit com a conta de usuário para obter tíquetes:

sudo kinit $SERVICEACCOUNT@DOMAIN

Por exemplo:

sudo kinit ad_admin@CONTOSO.COM

Configuração do RHEL 8 ao usar o protocolo duplo

As etapas a seguir são opcionais. Siga as etapas apenas se você usar o mapeamento de usuário no cliente NFS:

Conclua todas as etapas descritas na seção Configuração do RHEL 8 ao usar a criptografia Kerberos do NFS v4.1.
Adicione um registro DNS estático em seu arquivo /etc/hosts para usar o FQDN (nome de domínio totalmente qualificado) em seu Azure AD em vez do endereço IP no arquivo de configuração SSSD:

cat /etc/hosts
10.6.1.4 winad2016.contoso.com
Adicione uma seção adicional para domínios a fim de resolver identificadores do servidor LDAP do Azure AD:

[root@reddoc cbs]# cat /etc/sssd/sssd.conf
[sssd]
domains = contoso.com, contoso-ldap (new entry added for LDAP as id_provider)
config_file_version = 2
services = nss, pam, ssh, sudo (ensure nss is present in this list)

[domain/contoso-ldap] (Copy the following lines. Modify as per your domain name.)
auth_provider = krb5
chpass_provider = krb5
id_provider = ldap
ldap_search_base = dc=contoso,dc=com(your domain)
ldap_schema = rfc2307bis
ldap_sasl_mech = GSSAPI
ldap_user_object_class = user
ldap_group_object_class = group
ldap_user_home_directory = unixHomeDirectory
ldap_user_principal = userPrincipalName
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = true
ldap_user_search_base = cn=Users,dc=contoso,dc=com (based on your domain)
ldap_group_search_base = cn=Users,dc=contoso,dc=com (based on your domain)
ldap_sasl_authid = REDDOC$ (ensure $ at the end you can get this from “klist -kte” command)
krb5_server = winad2016.contoso.com (same as AD address which is added in /etc/hosts)
krb5_realm = CONTOSO.COM (domain name in caps)
krb5_kpasswd = winad2016.contoso.com (same as AD address which is added in /etc/hosts)
use_fully_qualified_names = false

Na configuração [domain/contoso-ldap] acima:
- id_provider é definido como ldap e não ad.
- A configuração especificou bases de pesquisa e classes de usuário e grupo para pesquisas.
- ldap_sasl_authid é o nome da conta do computador de klist -kte.
- use_fully_qualified_names é definido como false. Essa definição significa que essa configuração é usada quando um nome curto é empregado.
- ldap_id_mapping NÃO é especificado, que usa false como padrão.
A configuração realm join é gerada pelo cliente e tem esta aparência:

[domain/contoso.com] (Do not edit or remove any of the following information. This information is automatically generated during the realm join process.)
ad_domain = contoso.com
krb5_realm = CONTOSO.COM
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = ad

Na configuração [domain/contoso.com] acima:
- id_provider é definido como ad.
- ldap_id_mapping é definido como true. Ela usa as IDs geradas pelo SSSD. Como alternativa, você pode definir esse valor como false se deseja usar os UIDs do POSIX para TODOS os estilos de nomes de usuário. Determine o valor com base na configuração do cliente.
- use_fully_qualified_names é true. Essa configuração significa que user@CONTOSO.COM usará essa configuração.
Verifique se o /etc/nsswitch.conf tem a entrada sss:

cat /etc/nsswitch.conf
passwd: sss files systemd
group: sss files systemd
netgroup: sss files
Reinicie o serviço sssd e limpe o cache:

service sssd stop
rm -f /var/lib/sss/db/*
service sssd start
Faça o teste para garantir que o cliente esteja integrado ao servidor LDAP:

[root@red81 cbs]# id ldapuser1
uid=1234(ldapuser1) gid=1111(ldapgroup1) groups=1111(ldapgroup1)

Configuração do Ubuntu

Esta seção descreve as configurações do Ubuntu necessárias para a criptografia Kerberos do NFS v4.1 e o protocolo duplo.

Os exemplos nesta seção usam o nome de domínio e o endereço IP a seguir:

Nome de domínio: contoso.com
IP privado: 10.6.1.4

Configure /etc/resolv.conf com o servidor DNS apropriado:

root@ubuntu-rak:/home/cbs# cat /etc/resolv.conf
search contoso.com
nameserver <private IP address of DNS server>
Adicione o registro de cliente NFS no servidor DNS para a zona de pesquisa inversa e de encaminhamento de DNS.

Para verificar o DNS, use os seguintes comandos no cliente NFS:

# nslookup [hostname/FQDN of NFS client(s)]
# nslookup [IP address of NFS client(s)]
Instalar pacotes:

apt-get update
apt-get install -y realmd packagekit sssd adcli samba-common chrony krb5-user nfs-common

Quando solicitado, insira $DOMAIN.NAME (usando letras maiúsculas, por exemplo, CONTOSO.COM) como o realm padrão do Kerberos.
Reinicie o serviço rpc-gssd.service:

sudo systemctl start rpc-gssd.service
O Ubuntu 18.04 usa chrony por padrão. Seguindo as diretrizes de configuração em Ubuntu Bionic: usando o chrony para configurar o NTP.
Ingressar em um domínio do Active Directory:

sudo realm join $DOMAIN.NAME -U $SERVICEACCOUNT --computer-ou="OU=$YOUROU"

Por exemplo:
sudo realm join CONTOSO.COM -U ad_admin --computer-ou="CN=Computers"
Execute kinit com o usuário para obter tíquetes:

sudo kinit $SERVICEACCOUNT

Por exemplo:
sudo kinit ad_admin

Configuração do Ubuntu ao usar o protocolo duplo

As etapas a seguir são opcionais. Siga as etapas apenas se você usar o mapeamento de usuário no cliente NFS:

Execute o seguinte comando para atualizar os pacotes instalados:
sudo apt update && sudo apt install libnss-ldap libpam-ldap ldap-utils nscd

O exemplo a seguir usa valores de exemplo. Quando o comando fizer uma solicitação a você, forneça o que está sendo pedido tendo como base seu ambiente.

base dc=contoso,dc=com uri ldap://10.20.0.4:389/ ldap_version 3 rootbinddn cn=admin,cn=Users,dc=contoso,dc=com pam_password ad
Verifique se o arquivo /etc/nsswitch.conf tem as seguintes entradas ldap:
passwd: compat systemd ldap
group: compat systemd ldap
Execute o comando a seguir para reiniciar e habilitar o serviço:

sudo systemctl restart nscd && sudo systemctl enable nscd

O exemplo a seguir consulta um usuário LDAP ‘hari1’ no servidor LDAP do Azure AD por meio do cliente LDAP do Ubuntu:

root@cbs-k8s-varun4-04:/home/cbs# getent passwd hari1
hari1:*:1237:1237:hari1:/home/hari1:/bin/bash

Configurar duas VMs com o mesmo nome de host para acessar volumes NFSv4.1

Esta seção explica como configurar duas VMs que têm o mesmo nome de host para acessar volumes NFSv 4.1 do Azure NetApp Files. Esse procedimento pode ser útil quando você realiza um teste de DR (recuperação de desastres) e exige um sistema de teste com o mesmo nome de host do sistema de DR primário. Esse procedimento só é necessário quando você tem o mesmo nome de host em duas VMs que estão acessando os mesmos volumes do Azure NetApp Files.

O NFSv4. x requer que cada cliente se identifique nos servidores com uma cadeia de caracteres exclusiva. O arquivo aberto e o estado de bloqueio compartilhados entre um cliente e um servidor são associados a essa identidade. Para dar suporte à recuperação de estado do NFSv4. x e à migração de estado transparente robusta, essa cadeia de caracteres de identidade não deve ser alterada entre reinicializações do cliente.

Exiba a cadeia de caracteres nfs4_unique_id nos clientes de VM usando o seguinte comando:

# systool -v -m nfs | grep -i nfs4_unique
nfs4_unique_id = ""

Para montar o mesmo volume em uma VM adicional com o mesmo nome de host, como o sistema de DR, crie um nfs4_unique_id para que ele possa se identificar exclusivamente para o serviço NFS do Azure NetApp Files. Esta etapa permite que o serviço faça a distinção entre as duas VMs com o mesmo nome de host e habilite a montagem de volumes NFSv 4.1 em ambas as VMs.

Você precisa executar esta etapa somente no sistema de DR. Para consistência, você pode considerar a aplicação de uma configuração exclusiva em cada máquina virtual envolvida.
No sistema de DR de teste, adicione a seguinte linha ao arquivo nfsclient.conf, normalmente localizado em /etc/modprobe.d/:

options nfs nfs4_unique_id=uniquenfs4-1

A cadeia de caracteres uniquenfs4-1 pode ser qualquer cadeia de caracteres alfanumérica, desde que seja exclusiva entre as VMs a serem conectadas ao serviço.

Verifique a documentação da distribuição sobre como definir as configurações do cliente NFS.

Reinicialize a VM para que a alteração entre em vigor.
No sistema de teste de DR, verifique se o nfs4_unique_id foi definido após a reinicialização da VM:

# systool -v -m nfs | grep -i nfs4_unique
nfs4_unique_id = "uniquenfs4-1"
Monte o volume NFSv4.1 em ambas as VMs como de costume.

Ambas as VMs com o mesmo nome de host agora podem montar e acessar o volume NFSv 4.1.

Compartilhar via