Partilhar via


Configurar um cliente NFS para o Azure NetApp Files

A configuração do cliente NFS descrita neste artigo faz parte da configuração quando você configura a criptografia Kerberos NFSv4.1 ou cria um volume de protocolo duplo ou NFSv3/NFSv4.1 com LDAP. Uma grande variedade de distribuições Linux está disponível para uso com os Arquivos NetApp do Azure. Este artigo descreve as configurações para dois dos ambientes mais usados: RHEL 8 e Ubuntu 18.04.

Requisitos e considerações

Independentemente do sabor Linux que você usa, as seguintes configurações são necessárias:

  • Configure um cliente NTP para evitar problemas com a distorção de tempo.
  • Configure entradas DNS do cliente Linux para resolução de nomes.
    Esta configuração deve incluir o registo "A" (para a frente) e o registo PTR (reverso).
  • Para ingresso no domínio, crie uma conta de computador para o cliente Linux no Ative Directory de destino (que é criado durante o comando realm join).

    Nota

    A $SERVICEACCOUNT variável 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 RHEL necessárias para criptografia Kerberos NFSv4.1 e protocolo duplo.

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

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

Configuração do RHEL 8 se você estiver usando a criptografia Kerberos NFSv4.1

  1. Configure /etc/resolv.conf com o servidor DNS adequado.

    Por exemplo:

    [root@reddoc cbs]# cat /etc/resolv.conf
    search contoso.com
    nameserver 10.6.1.4(private IP)

  2. Adicione o registro do cliente NFS no servidor DNS para a zona de pesquisa direta e inversa do DNS.

  3. Para verificar o DNS, use os seguintes comandos do cliente NFS:

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

  4. Instalar pacotes:

    yum update
    sudo yum -y install realmd sssd adcli samba-common krb5-workstation chrony nfs-utils

  5. Configure o cliente NTP.

    O RHEL 8 usa crony por padrão.

  6. Junte-se ao domínio do Ative 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 está definido para o domínio fornecido em /etc/krb5.conf. Caso contrário, adicione-o [libdefaults] na seção 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
    
  7. Reinicie todos os serviços NFS:

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

    A reinicialização evita a condição “mount.nfs: an incorrect mount option was specified” de erro durante a montagem do Kerberos.

  8. Execute o kinit comando com a conta de usuário para obter tickets:

    sudo kinit $SERVICEACCOUNT@DOMAIN

    Por exemplo:

    sudo kinit ad_admin@CONTOSO.COM

Configuração do RHEL 8 se você estiver usando protocolo duplo

As etapas a seguir são opcionais. Você precisará executar as etapas somente se usar o mapeamento de usuário no cliente NFS:

  1. Conclua todas as etapas descritas na configuração do RHEL 8 se estiver usando a seção de criptografia Kerberos NFSv4.1.

  2. Adicione um registro DNS estático em seu arquivo /etc/hosts para usar o nome de domínio totalmente qualificado (FQDN) para seu AD, em vez de usar o endereço IP no arquivo de configuração do SSSD:

    cat /etc/hosts
    10.6.1.4 winad2016.contoso.com

  3. Adicione uma seção extra para domínios para resolver identificadores do servidor LDAP do 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

    [domain/contoso-ldap] Na configuração acima:

    • id_provider está 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 da máquina de klist -kte.
    • use_fully_qualified_names está definido como false. Essa configuração significa que essa configuração é usada quando um nome curto é usado.
    • ldap_id_mapping é NÃO especificado, cujo padrão é false.

    A realm join configuração é 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

    [domain/contoso.com] Na configuração acima:

    • id_provider está definido como ad.
    • ldap_id_mapping está definido como true. Ele usa as IDs geradas pelo SSSD. Como alternativa, você pode definir esse valor como false se quiser usar UIDs POSIX para TODOS os estilos de nomes de usuário. Você pode determinar 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.
  4. /etc/nsswitch.conf Certifique-se de que tem a sss entrada:

    cat /etc/nsswitch.conf
    passwd: sss files systemd
    group: sss files systemd
    netgroup: sss files

  5. Reinicie o serviço e limpe o sssd cache:

    service sssd stop
    rm -f /var/lib/sss/db/*
    service sssd start

  6. Teste para garantir que seu 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 criptografia Kerberos NFSv4.1 e protocolo duplo.

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

  • Nome de domínio: contoso.com
  • IP privado: 10.6.1.4
  1. Configure /etc/resolv.conf com o servidor DNS adequado:

    root@ubuntu-rak:/home/cbs# cat /etc/resolv.conf
    search contoso.com
    nameserver <private IP address of DNS server>

  2. Adicione o registro do cliente NFS no servidor DNS para a zona de pesquisa direta e inversa do DNS.

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

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

  3. 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 maiúsculas, por exemplo, CONTOSO.COM) como o realm Kerberos padrão.

  4. Reinicie o serviço rpc-gssd.service:

    sudo systemctl start rpc-gssd.service

  5. Ubuntu 18.04 usa crony por padrão. Seguindo as diretrizes de configuração no Ubuntu Bionic: Usando crony para configurar o NTP.

  6. Junte-se ao domínio do Ative 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"

  7. Realize kinit com o usuário para obter ingressos:

    sudo kinit $SERVICEACCOUNT

    Por exemplo:
    sudo kinit ad_admin

Configuração do Ubuntu se você estiver usando protocolo duplo

As etapas a seguir são opcionais. Você precisa executar as etapas somente se quiser usar o mapeamento de usuário no cliente NFS:

  1. 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 solicita entrada, você deve fornecer entrada com base em 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

  2. Certifique-se de que o seu /etc/nsswitch.conf ficheiro tem as seguintes ldap entradas:
    passwd: compat systemd ldap
    group: compat systemd ldap

  3. Execute o seguinte comando para reiniciar e habilitar o serviço:

    sudo systemctl restart nscd && sudo systemctl enable nscd

O exemplo a seguir consulta o servidor LDAP do AD do cliente LDAP do Ubuntu para um usuário ‘hari1’LDAP:

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 você pode configurar duas VMs que têm o mesmo nome de host para acessar os volumes NFSv4.1 do Azure NetApp Files. Este procedimento pode ser útil quando você conduz um teste de recuperação de desastres (DR) e requer um sistema de teste com o mesmo nome de host do sistema DR primário. Este 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 em servidores com uma cadeia de caracteres exclusiva . O estado de abertura e bloqueio de arquivo compartilhado entre um cliente e um servidor está associado a essa identidade. Para oferecer suporte à recuperação de estado NFSv4.x robusta e à migração de estado transparente, essa cadeia de caracteres de identidade não deve ser alterada nas reinicializações do cliente.

  1. Exiba a nfs4_unique_id cadeia de caracteres nos clientes 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, por exemplo, o sistema DR, crie um nfs4_unique_id para que ele possa se identificar exclusivamente no serviço NFS do Azure NetApp Files. Esta etapa permite que o serviço distinga entre as duas VMs com o mesmo nome de host e habilite a montagem de volumes NFSv4.1 em ambas as VMs.

    Você precisa executar esta etapa somente no sistema DR de teste. Para consistência, você pode considerar a aplicação de uma configuração exclusiva em cada máquina virtual envolvida.

  2. No sistema DR de teste, adicione a seguinte linha ao nfsclient.conf arquivo, normalmente localizado em /etc/modprobe.d/:

    options nfs nfs4_unique_id=uniquenfs4-1

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

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

    Reinicialize a VM para que a alteração entre em vigor.

  3. No sistema DR de teste, verifique se 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"

  4. Monte o volume NFSv4.1 em ambas as VMs normalmente.

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

Próximos passos