Ir para o conteúdoIr para navegação de página: página anterior [tecla de acesso p]/próxima página [tecla de acesso n]
documentation.suse.com / Documentação do SUSE Enterprise Storage 7 / Guia de Operações e Administração / Acessando os dados do cluster / Exportar dados do Ceph por meio do Samba
Aplica-se a SUSE Enterprise Storage 7

24 Exportar dados do Ceph por meio do Samba

Este capítulo descreve como exportar os dados armazenados em um cluster do Ceph por meio de um compartilhamento do Samba/CIFS para que você possa acessá-los facilmente de máquinas cliente Windows*. Ele também inclui informações que ajudarão você a configurar um gateway do Samba para o Ceph a fim de ingressar o Active Directory no domínio do Windows* para autenticar e autorizar usuários.

Nota
Nota: Desempenho do gateway do Samba

Devido ao aumento da sobrecarga do protocolo e da latência adicional causado por saltos extras de rede entre o cliente e o armazenamento, o acesso ao CephFS por meio de um Gateway do Samba pode reduzir significativamente o desempenho do aplicativo quando comparado aos clientes nativos do Ceph.

24.1 Exportar o CephFS por meio do compartilhamento do Samba

Atenção
Atenção: Acesso a vários protocolos

Os clientes nativos CephFS e NFS não são restritos por bloqueios de arquivos obtidos por meio do Samba, e vice-versa. Os aplicativos que dependem do bloqueio de arquivos compatível com vários protocolos poderão ter os dados corrompidos se os caminhos de compartilhamento do Samba com suporte do CephFS forem acessados por outros meios.

24.1.1 Configurando e exportando pacotes do Samba

Para configurar e exportar um compartilhamento do Samba, os seguintes pacotes precisam ser instalados: samba-ceph e samba-winbind. Se esses pacotes não foram instalados, instale-os:

cephuser@smb > zypper install samba-ceph samba-winbind

24.1.2 Exemplo de gateway único

Em preparação para exportar um compartilhamento do Samba, escolha um nó apropriado para agir como Gateway do Samba. O nó precisa ter acesso à rede de clientes do Ceph, além de CPU, memória e recursos de rede suficientes.

É possível fornecer a funcionalidade de failover com o CTDB e a SUSE Linux Enterprise High Availability Extension. Consulte a Seção 24.1.3, “Configuring a alta disponibilidade” para obter mais informações sobre configuração de Alta Disponibilidade.

  1. Verifique se já existe um CephFS em execução no cluster.

  2. Crie um chaveiro específico do Gateway do Samba no nó de admin do Ceph e copie-o para os dois nós do Gateway do Samba:

    cephuser@adm > ceph auth get-or-create client.samba.gw mon 'allow r' \
     osd 'allow *' mds 'allow *' -o ceph.client.samba.gw.keyring
    cephuser@adm > scp ceph.client.samba.gw.keyring SAMBA_NODE:/etc/ceph/

    Substitua SAMBA_NODE pelo nome do nó do gateway do Samba.

  3. As etapas a seguir são executadas no nó do Gateway do Samba. Instale o Samba com o pacote de integração do Ceph:

    cephuser@smb > sudo zypper in samba samba-ceph
  4. Substitua o conteúdo padrão do arquivo /etc/samba/smb.conf com o seguinte:

    [global]
      netbios name = SAMBA-GW
      clustering = no
      idmap config * : backend = tdb2
      passdb backend = tdbsam
      # disable print server
      load printers = no
      smbd: backgroundqueue = no
    
    [SHARE_NAME]
      path = CEPHFS_MOUNT
      read only = no
      oplocks = no
      kernel share modes = no

    O caminho CEPHFS_MOUNT acima deve ser montado antes de iniciar o Samba com uma configuração de compartilhamento do CephFS do kernel. Consulte a Seção 23.3, “Montando o CephFS em /etc/fstab.

    A configuração de compartilhamento acima usa o cliente CephFS do kernel do Linux, que é recomendado por motivos de desempenho. Outra opção é usar o módulo vfs_ceph do Samba para comunicação com o cluster do Ceph. As instruções mostradas abaixo são para uso legado e não são recomendadas para novas implantações do Samba:

    [SHARE_NAME]
      path = /
      vfs objects = ceph
      ceph: config_file = /etc/ceph/ceph.conf
      ceph: user_id = samba.gw
      read only = no
      oplocks = no
      kernel share modes = no
    Dica
    Dica: Oplocks e modos de compartilhamento

    Os oplocks (também conhecidos como concessões do SMB2+) proporciona melhor desempenho por meio de armazenamento em cahe de cliente agressivo, mas não é seguro atualmente quando o Samba é implantado com outros clientes CephFS, como mount.ceph do kernel, FUSE ou NFS Ganesha.

    Se todo o acesso do caminho do sistema de arquivos CephFS for processado exclusivamente pelo Samba, o parâmetro oplocks poderá ser habilitado com segurança.

    No momento, os modos de compartilhamento do kernel precisam ser desabilitados em um compartilhamento executado com o módulo vfs do CephFS para que o processamento do arquivo funcione apropriadamente.

    Importante
    Importante: permitindo acesso

    O Samba mapeia usuários e grupos do SMB para contas locais. Os usuários locais podem receber uma senha para acesso ao compartilhamento do Samba por meio de:

    root # smbpasswd -a USERNAME

    Para uma E/S bem-sucedida, a lista de controles de acesso (ACL, Access Control List) do caminho do compartilhamento precisa permitir o acesso ao usuário conectado pelo Samba. É possível modificar a ACL por uma montagem temporária por meio do cliente do kernel CephFS e usando os utilitários chmod, chown ou setfacl no caminho do compartilhamento. Por exemplo, para permitir o acesso de todos os usuários, execute:

    root # chmod 777 MOUNTED_SHARE_PATH

24.1.2.1 Iniciando serviços do Samba

Inicie ou reinicie serviços independentes do Samba usando os seguintes comandos:

root # systemctl restart smb.service
root # systemctl restart nmb.service
root # systemctl restart winbind.service

Para garantir que os serviços do Samba sejam iniciados na inicialização, execute este comando para habilitá-los:

root # systemctl enable smb.service
root # systemctl enable nmb.service
root # systemctl enable winbind.service
Dica
Dica: Serviços opcionais nmb e winbind

Se você não precisar da pesquisa de compartilhamento de rede, não precisará habilitar e iniciar o serviço nmb.

O serviço winbind apenas é necessário quando configurado como um membro de domínio do Active Directory. Consulte a Seção 24.2, “Ingressando no Gateway do Samba e no Active Directory”.

24.1.3 Configuring a alta disponibilidade

Importante
Importante: failover transparente não suportado

Embora uma implantação de vários nós do Samba + CTDB tenha disponibilidade mais alta em comparação com o nó único (consulte o Capítulo 24, Exportar dados do Ceph por meio do Samba), o failover transparente executado no cliente não é suportado. Os aplicativos provavelmente sofrerão uma breve interrupção no momento da falha do nó do Gateway do Samba.

Esta seção apresenta um exemplo de como definir uma configuração de dois nós de alta disponibilidade dos servidores Samba. A configuração requer a SUSE Linux Enterprise High Availability Extension. Os dois nós são denominados earth (192.168.1.1) e mars (192.168.1.2).

Para obter detalhes sobre a SUSE Linux Enterprise High Availability Extension, consulte https://documentation.suse.com/sle-ha/15-SP1/.

Além disso, dois endereços IP virtuais flutuantes permitem aos clientes se conectarem ao serviço independentemente do nó físico no qual está sendo executado. 192.168.1.10 é usado para administração do cluster com Hawk2, e 192.168.2.1 é usado exclusivamente para exportações CIFS. Isso facilita aplicar as restrições de segurança mais tarde.

O procedimento a seguir descreve a instalação de exemplo. Mais detalhes podem ser encontrados em https://documentation.suse.com/sle-ha/15-SP2/html/SLE-HA-all/art-sleha-install-quick.html.

  1. Crie um chaveiro específico do Gateway do Samba no Nó de Admin e copie-o para os dois nós:

    cephuser@adm > ceph auth get-or-create client.samba.gw mon 'allow r' \
        osd 'allow *' mds 'allow *' -o ceph.client.samba.gw.keyring
    cephuser@adm > scp ceph.client.samba.gw.keyring earth:/etc/ceph/
    cephuser@adm > scp ceph.client.samba.gw.keyring mars:/etc/ceph/
  2. A configuração de SLE-HA requer um dispositivo de fencing para evitar uma situação de split brain quando os nós do cluster ativos perdem a sincronização. Para essa finalidade, você pode usar uma imagem RBD do Ceph com o Dispositivo de Blocos Stonith (SBD, Stonith Block Device). Consulte https://documentation.suse.com/sle-ha/15-SP2/html/SLE-HA-all/cha-ha-storage-protect.html#sec-ha-storage-protect-fencing-setup para obter mais detalhes.

    Se ele ainda não existir, crie um pool RBD chamado rbd (consulte a Seção 18.1, “Criando um pool”) e associe-o ao rbd (consulte a Seção 18.5.1, “Associando pools a um aplicativo”). Em seguida, crie uma imagem RBD relacionada chamada sbd01:

    cephuser@adm > ceph osd pool create rbd
    cephuser@adm > ceph osd pool application enable rbd rbd
    cephuser@adm > rbd -p rbd create sbd01 --size 64M --image-shared
  3. Prepare o earth e o mars para hospedar o serviço do Samba:

    1. Verifique se os seguintes pacotes estão instalados antes de continuar: ctdb, tdb-tools e samba.

      root # zypper in ctdb tdb-tools samba samba-ceph
    2. Verifique se os serviços Samba e CTDB estão parados e desabilitados:

      root # systemctl disable ctdb
      root # systemctl disable smb
      root # systemctl disable nmb
      root # systemctl disable winbind
      root # systemctl stop ctdb
      root # systemctl stop smb
      root # systemctl stop nmb
      root # systemctl stop winbind
    3. Abra a porta 4379 do seu firewall em todos os nós. Isso é necessário para o CTDB se comunicar com outros nós do cluster.

  4. No earth, crie os arquivos de configuração para o Samba. Mais tarde, eles serão sincronizados automaticamente com o mars.

    1. Insira uma lista de endereços IP particulares dos nós do Gateway do Samba no arquivo /etc/ctdb/nodes. Encontre mais detalhes na página de manual do ctdb (man 7 ctdb).

      192.168.1.1
      192.168.1.2
    2. Configure o Samba. Adicione as seguintes linhas à seção [global] do /etc/samba/smb.conf. Use o nome de host de sua escolha em vez CTDB-SERVER (todos os nós no cluster aparecerão como um nó grande com esse nome). Adicione também uma definição do compartilhamento. Considere SHARE_NAME como um exemplo:

      [global]
        netbios name = SAMBA-HA-GW
        clustering = yes
        idmap config * : backend = tdb2
        passdb backend = tdbsam
        ctdbd socket = /var/lib/ctdb/ctdb.socket
        # disable print server
        load printers = no
        smbd: backgroundqueue = no
      
      [SHARE_NAME]
        path = /
        vfs objects = ceph
        ceph: config_file = /etc/ceph/ceph.conf
        ceph: user_id = samba.gw
        read only = no
        oplocks = no
        kernel share modes = no

      Observe que os arquivos /etc/ctdb/nodes e /etc/samba/smb.conf precisam ser iguais em todos os nós do Gateway do Samba.

  5. Instale e inicialize o cluster da SUSE Linux Enterprise High Availability.

    1. Registre a SUSE Linux Enterprise High Availability Extension no earth e no mars:

      root@earth # SUSEConnect -r ACTIVATION_CODE -e E_MAIL
      root@mars # SUSEConnect -r ACTIVATION_CODE -e E_MAIL
    2. Instale o ha-cluster-bootstrap em ambos os nós:

      root@earth # zypper in ha-cluster-bootstrap
      root@mars # zypper in ha-cluster-bootstrap
    3. Mapeie a imagem RBD sbd01 nos dois Gateways do Samba usando rbdmap.service.

      Edite /etc/ceph/rbdmap e adicione uma entrada para a imagem SBD:

      rbd/sbd01 id=samba.gw,keyring=/etc/ceph/ceph.client.samba.gw.keyring

      Habilite e inicie o rbdmap.service:

      root@earth # systemctl enable rbdmap.service && systemctl start rbdmap.service
      root@mars # systemctl enable rbdmap.service && systemctl start rbdmap.service

      O dispositivo /dev/rbd/rbd/sbd01 deve estar disponível em ambos os Gateways do Samba.

    4. Inicialize o cluster no earth e permita que mars ingresse nele.

      root@earth # ha-cluster-init
      root@mars # ha-cluster-join -c earth
      Importante
      Importante

      Durante o processo de inicialização e ingresso no cluster, será questionado se você deseja usar o SBD. Confirme com y e depois especifique /dev/rbd/rbd/sbd01 como o caminho para o dispositivo de armazenamento.

  6. Verifique o status do cluster. Você deve ver dois nós adicionados ao cluster:

    root@earth # crm status
    2 nodes configured
    1 resource configured
    
    Online: [ earth mars ]
    
    Full list of resources:
    
     admin-ip       (ocf::heartbeat:IPaddr2):       Started earth
  7. Execute os seguintes comandos no earth para configurar o recurso CTDB:

    root@earth # crm configure
    crm(live)configure# primitive ctdb ocf:heartbeat:CTDB params \
        ctdb_manages_winbind="false" \
        ctdb_manages_samba="false" \
        ctdb_recovery_lock="!/usr/lib64/ctdb/ctdb_mutex_ceph_rados_helper
            ceph client.samba.gw cephfs_metadata ctdb-mutex"
        ctdb_socket="/var/lib/ctdb/ctdb.socket" \
            op monitor interval="10" timeout="20" \
            op start interval="0" timeout="200" \
            op stop interval="0" timeout="100"
    crm(live)configure# primitive smb systemd:smb \
        op start timeout="100" interval="0" \
        op stop timeout="100" interval="0" \
        op monitor interval="60" timeout="100"
    crm(live)configure# primitive nmb systemd:nmb \
        op start timeout="100" interval="0" \
        op stop timeout="100" interval="0" \
        op monitor interval="60" timeout="100"
    crm(live)configure# primitive winbind systemd:winbind \
        op start timeout="100" interval="0" \
        op stop timeout="100" interval="0" \
        op monitor interval="60" timeout="100"
    crm(live)configure# group g-ctdb ctdb winbind nmb smb
    crm(live)configure# clone cl-ctdb g-ctdb meta interleave="true"
    crm(live)configure# commit
    Dica
    Dica: Primitivos opcionais nmb e winbind

    Se você não precisar da pesquisa de compartilhamento de rede, não precisará adicionar o primitivo nmb.

    O primitivo winbind apenas é necessário quando configurado como membro do domínio do Active Directory. Consulte a Seção 24.2, “Ingressando no Gateway do Samba e no Active Directory”.

    O binário /usr/lib64/ctdb/ctdb_mutex_ceph_rados_helper na opção de configuração ctdb_recovery_lock tem os parâmetros CLUSTER_NAME, CEPHX_USER, RADOS_POOL e RADOS_OBJECT, nessa ordem.

    Um parâmetro de tempo de espera de bloqueio extra pode ser anexado para anular o valor padrão usado (10 segundos). Um valor mais alto aumentará o tempo de failover do master de recuperação CTDB, enquanto um valor menor pode resultar na detecção incorreta do master de recuperação como inativo, provocando oscilação de failovers.

  8. Adicione um endereço IP em cluster:

    crm(live)configure# primitive ip ocf:heartbeat:IPaddr2
        params ip=192.168.2.1 \
        unique_clone_address="true" \
        op monitor interval="60" \
        meta resource-stickiness="0"
    crm(live)configure# clone cl-ip ip \
        meta interleave="true" clone-node-max="2" globally-unique="true"
    crm(live)configure# colocation col-with-ctdb 0: cl-ip cl-ctdb
    crm(live)configure# order o-with-ctdb 0: cl-ip cl-ctdb
    crm(live)configure# commit

    Se unique_clone_address for definido como true, o agente de recurso IPaddr2 adicionará um ID de clone ao endereço especificado, resultando em três endereços IP diferentes. Geralmente, eles não são necessários, mas ajudam no equilíbrio de carga. Para obter mais informações sobre este tópico, consulte https://documentation.suse.com/sle-ha/15-SP2/html/SLE-HA-all/cha-ha-lb.html.

  9. Verifique o resultado:

    root@earth # crm status
    Clone Set: base-clone [dlm]
         Started: [ factory-1 ]
         Stopped: [ factory-0 ]
     Clone Set: cl-ctdb [g-ctdb]
         Started: [ factory-1 ]
         Started: [ factory-0 ]
     Clone Set: cl-ip [ip] (unique)
         ip:0       (ocf:heartbeat:IPaddr2):       Started factory-0
         ip:1       (ocf:heartbeat:IPaddr2):       Started factory-1
  10. Faça o teste de uma máquina cliente. Em um cliente Linux, execute o seguinte comando para ver se você pode copiar arquivos do sistema e para o sistema:

    root # smbclient //192.168.2.1/myshare

24.1.3.1 Reiniciando os recursos de HA do Samba

Após qualquer mudança de configuração do Samba ou CTDB, os recursos de HA talvez tenham de ser reiniciados para que as mudanças entrem em vigor. Isso pode ser feito pelo comando:

root # crm resource restart cl-ctdb

24.2 Ingressando no Gateway do Samba e no Active Directory

Você pode configurar o gateway do Samba para Ceph para se tornar um membro do domínio do Samba com suporte ao Active Directory (AD). Como membro do domínio do Samba, você pode utilizar usuários e grupos de domínio em listas de acesso (ACLs) locais em arquivos e diretórios do CephFS exportado.

24.2.1 Preparando a instalação do Samba

Esta seção apresenta as etapas preparatórias que você precisa executar antes de configurar o próprio Samba. Começar com um ambiente limpo ajuda você a evitar confusão e verificar se nenhum arquivo da instalação do Samba anterior está misturado com a nova instalação do membro do domínio.

Dica
Dica: Sincronizando relógios

Todos os relógios dos nós do Gateway do Samba precisam ser sincronizados com o controlador de Domínio do Active Directory. Uma divergência no relógio pode resultar em falhas na autenticação.

Verifique se não há processos de cache de nome ou do Samba em execução:

cephuser@smb > ps ax | egrep "samba|smbd|nmbd|winbindd|nscd"

Se a saída listar quaisquer processos samba, smbd, nmbd, winbindd ou nscd, pare-os.

Se você já executou uma instalação do Samba neste host, remova o arquivo /etc/samba/smb.conf. Remova também todos os arquivos de banco de dados Samba, como *.tdb e *.ldb. Para listar os diretórios que contêm os bancos de dados Samba, execute:

cephuser@smb > smbd -b | egrep "LOCKDIR|STATEDIR|CACHEDIR|PRIVATE_DIR"

24.2.2 Verificando o DNS

O Active Directory (AD) usa o DNS para localizar outros controladores de domínio (DCs) e serviços, como o Kerberos. Portanto, os membros do domínio e os servidores do AD precisam ser capazes de resolver as zonas DNS do AD.

Verifique se o DNS está configurado corretamente e se ambas as pesquisas avançada e reversa são resolvidas corretamente, por exemplo:

cephuser@adm > nslookup DC1.domain.example.com
Server:         10.99.0.1
Address:        10.99.0.1#53

Name:   DC1.domain.example.com
Address: 10.99.0.1
cephuser@adm > 10.99.0.1
Server:        10.99.0.1
Address:	10.99.0.1#53

1.0.99.10.in-addr.arpa	name = DC1.domain.example.com.

24.2.3 Resolvendo registros SRV

O AD usa os registros SRV para localizar serviços, como Kerberos e LDAP. Para verificar se os registros SRV foram resolvidos corretamente, use o shell interativo nslookup. Por exemplo:

cephuser@adm > nslookup
Default Server:  10.99.0.1
Address:  10.99.0.1

> set type=SRV
> _ldap._tcp.domain.example.com.
Server:  UnKnown
Address:  10.99.0.1

_ldap._tcp.domain.example.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = dc1.domain.example.com
domain.example.com      nameserver = dc1.domain.example.com
dc1.domain.example.com  internet address = 10.99.0.1

24.2.4 Configurando o kerberos

O Samba suporta os back ends Heimdal e MIT do Kerberos. Para configurar o Kerberos no membro do domínio, defina o seguinte no arquivo /etc/krb5.conf:

[libdefaults]
	default_realm = DOMAIN.EXAMPLE.COM
	dns_lookup_realm = false
	dns_lookup_kdc = true

O exemplo anterior configura o Kerberos para o domínio Kerberos DOMAIN.EXAMPLE.COM. Não recomendamos definir nenhum outro parâmetro no arquivo /etc/krb5.conf. Se o /etc/krb5.conf contém uma linha include, ele não funcionará. Você deve remover essa linha.

24.2.5 Resolvendo o nome de host local

Quando você ingressa um host no domínio, o Samba tenta registrar o nome de host na zona DNS do AD. Para isso, o utilitário net precisa ser capaz de resolver o nome de host usando DNS ou uma entrada correta no arquivo /etc/hosts.

Para verificar se o nome de host foi resolvido corretamente, use o comando getent hosts:

cephuser@adm > getent hosts example-host
10.99.0.5      example-host.domain.example.com    example-host

O nome de host e o FQDN não devem ser resolvidos para o endereço IP 127.0.0.1 nem para qualquer endereço IP diferente do que foi usado na interface LAN do membro do domínio. Se nenhuma saída for exibida ou se o host for resolvido para o endereço IP incorreto, e você não estiver usando DHCP, defina a entrada correta no arquivo /etc/hosts:

127.0.0.1      localhost
10.99.0.5      example-host.samdom.example.com    example-host
Dica
Dica: DHCP e /etc/hosts

Se você estiver usando DHCP, confira se /etc/hosts contém apenas a linha “127.0.0.1”. Se os problemas persistirem, contate o administrador do seu servidor DHCP.

Se você precisa adicionar aliases ao nome de host da máquina, adicione-os ao fim da linha que começa com o endereço IP da máquina, e não à linha “127.0.0.1”.

24.2.6 Configurando o Samba

Esta seção apresenta informações sobre opções de configuração específicas que você precisa incluir na configuração do Samba.

A participação no domínio do Active Directory é configurada principalmente definindo security = ADS junto com os parâmetros apropriados de mapeamento de domínio e ID do Kerberos na seção [global] do /etc/samba/smb.conf.

[global]
  security = ADS
  workgroup = DOMAIN
  realm = DOMAIN.EXAMPLE.COM
  ...

24.2.6.1 Escolhendo o back end para mapeamento de ID no winbindd

Se você precisa que seus usuários tenham shells de login e/ou caminhos de diretório pessoal do Unix diferentes, ou se você deseja que eles tenham o mesmo ID em todos os lugares, será necessário usar o back end “ad” do winbind e adicionar os atributos RFC2307 ao AD.

Importante
Importante: atributos RFC2307 e Números de ID

Os atributos RFC2307 não são adicionados automaticamente quando os usuários ou grupos são criados.

Os números de ID encontrados em um DC (números na faixa de 3000000) não são atributos RFC2307 e não serão usados nos Membros do Domínio Unix. Se você precisa ter os mesmos números de ID em todos os lugares, adicione os atributos uidNumber e gidNumber ao AD e use o back end “ad” do winbind nos Membros do Domínio Unix. Se você adicionar os atributos uidNumber e gidNumber ao AD, não use números na faixa de 3000000.

Se os seus usuários utilizarão apenas o DC do AD para Samba para autenticação e não armazenarão dados nem efetuarão login nele, você poderá usar o back end “rid” do winbind. Isso calcula os IDs do usuário e do grupo do RID do Windows*. Se você usar a mesma seção [global] do smb.conf em cada membro do domínio Unix, obterá os mesmos IDs. Se você usar o back end “rid”, não precisará adicionar nada ao AD, e os atributos RFC2307 serão ignorados. Ao usar o back end “rid”, defina os parâmetros template shell e template homedir no smb.conf. Essas configurações são globais, e todos recebem o mesmo shell de login e caminho de diretório pessoal do Unix (ao contrário dos atributos RFC2307, em que você pode definir shells e caminhos de diretório pessoal do Unix individuais).

Há outra maneira de configurar o Samba: quando você precisa que seus usuários e grupos tenham o mesmo ID em todos os lugares, mas precisa apenas que seus usuários tenham o mesmo shell de login e usem o mesmo caminho de diretório pessoal do Unix. Para fazer isso, use o back end “ad” do winbind e as linhas de gabarito no smb.conf. Dessa forma, você precisa apenas adicionar os atributos uidNumber e gidNumber ao AD.

Dica
Dica: Mais Informações sobre Back Ends para Mapeamento de ID

Encontre informações mais detalhadas sobre os back ends de mapeamento de ID disponíveis nas páginas de manual relacionadas: man 8 idmap_ad, man 8 idmap_rid e man 8 idmap_autorid.

24.2.6.2 Definindo faixas de IDs de usuário e grupo

Após decidir qual back end do winbind será usado, você precisará especificar as faixas a serem usadas com a opção idmap config em smb.conf. Por padrão, há vários blocos de IDs de usuário e grupo reservados em um membro do domínio Unix:

Tabela 24.1: Blocos de IDs Padrão de Usuários e Grupos
IDsFaixa
0-999Usuários e grupos do sistema local.
A partir de 1000Usuários e grupos do Unix local.
A partir de 10000Usuários e grupos do DOMÍNIO.

Como é possível ver nas faixas acima, você não deve definir as faixas “*” ou “DOMÍNIO” para começar em 999 ou menos, pois elas interferem nos usuários e grupos do sistema local. Você também deve deixar um espaço para quaisquer usuários e grupos do Unix local. Dessa forma, começar as faixas idmap config em 3000 parece ser um bom compromisso.

Você precisa decidir o quanto seu "DOMÍNIO" poderá crescer e se você pretende ter quaisquer domínios confiáveis. Em seguida, você poderá definir as faixas idmap config da seguinte maneira:

Tabela 24.2: Faixas de ID
DomínioFaixa
*3000-7999
DOMÍNIO10000-999999
CONFIÁVEL1000000-9999999

24.2.6.3 Mapeando a conta de administrador de domínio para o usuário root local

O Samba permite mapear contas de domínio para uma conta local. Use esse recurso para executar operações de arquivo no sistema de arquivos do membro do domínio como um usuário diferente daquele da conta que solicitou a operação no cliente.

Dica
Dica: Mapeando o administrador de domínio (opcional)

O mapeamento do administrador de domínio para a conta root local é opcional. Configure o mapeamento apenas se o administrador de domínio precisa ter a capacidade de executar operações de arquivo no membro de domínio usando as permissões de root. Esteja ciente de que o mapeamento do Administrador para a conta root não permite que você efetue login nos membros do domínio Unix como “Administrador”.

Para mapear o administrador de domínio para a conta root local, siga estas etapas:

  1. Adicione o seguinte parâmetro à seção [global] do arquivo smb.conf:

    username map = /etc/samba/user.map
  2. Crie o arquivo /etc/samba/user.map com o seguinte conteúdo:

    !root = DOMAIN\Administrator
Importante
Importante

Ao usar o back end de mapeamento de ID “ad”, não defina o atributo uidNumber para a conta de administrador de domínio. Se a conta tiver o atributo definido, o valor anulará o UID “0” local do usuário root e, portanto, haverá falha no mapeamento.

Para obter mais detalhes, consulte o parâmetro username map na página de manual smb.conf (man 5 smb.conf).

24.2.7 Ingressando no domínio do Active Directory

Para que o host ingresse em um Active Directory, execute:

cephuser@smb > net ads join -U administrator
Enter administrator's password: PASSWORD
Using short domain name -- DOMAIN
Joined EXAMPLE-HOST to dns domain 'DOMAIN.example.com'

24.2.8 Configurando o Name Service Switch

Para disponibilizar usuários e grupos de domínio ao sistema local, você precisa habilitar a biblioteca NSS (Name Service Switch). Anexe a entrada winbind aos seguintes bancos de dados no arquivo /etc/nsswitch.conf:

passwd: files winbind
group:  files winbind
Importante
Importante: pontos a Serem Considerados
  • Mantenha a entrada files como a primeira origem para os dois bancos de dados. Desse modo, o NSS pode procurar os usuários e grupos de domínio dos arquivos /etc/passwd e /etc/group antes de consultar o serviço winbind.

  • Não adicione a entrada winbind ao banco de dados de sombra do NSS. Isso pode causar uma falha no utilitário wbinfo.

  • Não use no domínio os mesmos nomes de usuário do arquivo local /etc/passwd.

24.2.9 Iniciando os serviços

Após as mudanças de configuração, reinicie os serviços do Samba de acordo com a Seção 24.1.2.1, “Iniciando serviços do Samba” ou a Seção 24.1.3.1, “Reiniciando os recursos de HA do Samba”.

24.2.10 Testar a conectividade de winbindd

24.2.10.1 Enviando um ping de winbindd

Para verificar se o serviço winbindd pode se conectar aos Controladores de Domínio (DC, Domain Controllers) do AD ou a um PDC (Primary Domain Controller), digite:

cephuser@smb > wbinfo --ping-dc
checking the NETLOGON for domain[DOMAIN] dc connection to "DC.DOMAIN.EXAMPLE.COM" succeeded

Se houver falha no comando anterior, verifique se o serviço winbindd está em execução e se o arquivo smb.conf está configurado corretamente.

24.2.10.2 Pesquisando usuários e grupos de domínio

A biblioteca libnss_winbind permite pesquisar usuários e grupos de domínio. Por exemplo, para pesquisar usuário de domínio “DOMAIN\demo01”:

cephuser@smb > getent passwd DOMAIN\\demo01
DOMAIN\demo01:*:10000:10000:demo01:/home/demo01:/bin/bash

Para pesquisar o grupo de domínio “Domain Users”:

cephuser@smb > getent group "DOMAIN\\Domain Users"
DOMAIN\domain users:x:10000:

24.2.10.3 Atribuindo permissões de arquivo a usuários e grupos de domínio

A biblioteca NSS (Name Service Switch) permite usar contas de usuário e grupos de domínio em comandos. Por exemplo, para definir o proprietário de um arquivo como o usuário de domínio “demo01”, e o grupo como o grupo de domínio "Domain Users", digite:

cephuser@smb > chown "DOMAIN\\demo01:DOMAIN\\domain users" file.txt