Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Aplica-se a SUSE Enterprise Storage 6

20 Exportando 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.

20.1 Exportando 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.

20.1.1 Instalação de pacotes relacionados ao 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:

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

20.1.2 Exemplo de gateway único

Em preparação para a exportação de um compartilhamento do Samba, escolha um nó apropriado para atuar 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 20.1.3, “Configuração de 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. Para obter os detalhes, consulte o Capítulo 11, Instalação do CephFS.

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

    cephadm@adm > ceph auth get-or-create client.samba.gw mon 'allow r' \
     osd 'allow *' mds 'allow *' -o ceph.client.samba.gw.keyring
    root@master # 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:

    cephadm@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 = /
      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

    O oplocks (também conhecido como concessões de 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.cephfs 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

    Como o vfs_ceph não exige montagem de um sistema de arquivos, o caminho do compartilhamento é interpretado como um caminho absoluto no sistema de arquivos do Ceph no cluster do Ceph anexado. Para E/S bem-sucedida do compartilhamento, a lista de controle de acesso (ACL, Access Control List) do caminho precisa permitir acesso do usuário mapeado para o cliente específico do 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
  5. Inicie e habilite o daemon do Samba:

    cephadm@smb > sudo systemctl start smb.service
    cephadm@smb > sudo systemctl enable smb.service
    cephadm@smb > sudo systemctl start nmb.service
    cephadm@smb > sudo systemctl enable nmb.service

20.1.3 Configuração de 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 20, Exportando 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://www.suse.com/documentation/sle-ha-15/.

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://www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/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:

    cephadm@adm > ceph auth get-or-create client.samba.gw mon 'allow r' \
        osd 'allow *' mds 'allow *' -o ceph.client.samba.gw.keyring
    root@master # scp ceph.client.samba.gw.keyring earth:/etc/ceph/
    root@master # scp ceph.client.samba.gw.keyring mars:/etc/ceph/
  2. 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 (necessário para os recursos smb e nmb).

      cephadm@smb > zypper in ctdb tdb-tools samba samba-ceph
    2. Verifique se os serviços ctdb, smb e nmb estão parados e desabilitados:

      cephadm@smb > sudo systemctl disable ctdb
      cephadm@smb > sudo systemctl disable smb
      cephadm@smb > sudo systemctl disable nmb
      cephadm@smb > sudo systemctl stop smb
      cephadm@smb > sudo systemctl stop nmb
    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.

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

    1. Em /etc/ctdb/nodes, insira todos os nós que contêm todos os endereços IP privados de cada nó no cluster:

      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 de "CTDB-SERVER" (todos os nós no cluster aparecerão como um nó grande com esse nome, efetivamente). 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.

  4. 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. Inicialize o cluster no earth:

      root@earth # ha-cluster-init
    4. Permita que o mars ingresse no cluster:

      root@mars # ha-cluster-join -c earth
  5. 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
  6. 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 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 smb systemd:smb \
        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 nmb smb
    crm(live)configure# clone cl-ctdb g-ctdb meta interleave="true"
    crm(live)configure# commit

    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.

  7. 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://www.suse.com/documentation/sle-ha-15/book_sleha_guide/data/cha_ha_lb.html.

  8. 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
  9. 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

20.2 Gateway do Samba ingressando 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.

20.2.1 Preparação

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: Sincronizar 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:

cephadm@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:

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

20.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:

cephadm@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
cephadm@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.

20.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:

cephadm@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

20.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.

20.2.5 Resolução de 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:

cephadm@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”.

20.2.6 Configurando o Samba

Esta seção apresenta informações sobre opções de configuração específicas que você precisa incluir no arquivo de configuração /etc/samba/smb.conf do Samba.

20.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.

20.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 usuários e grupos em um membro do domínio Unix:

Tabela 20.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 20.2: Faixas de ID
DomínioFaixa
*3000-7999
DOMÍNIO10000-999999
CONFIÁVEL1000000-9999999

20.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).

20.2.7 Ingressando no domínio do Active Directory

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

cephadm@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'

20.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.

20.2.9 Iniciando os serviços

Há três serviços que você precisa habilitar e iniciar para ter um membro do domínio Unix em pleno funcionamento: smbd, nmbd e winbindd. Habilite-os e inicie-os usando os seguintes comandos:

cephadm@smb > sudo systemctl enable smbd.service && systemctl start smbd.service
cephadm@smb > sudo systemctl enable nmbd.service && systemctl start nmbd.service
cephadm@smb > sudo systemctl enable winbindd.service && systemctl start winbindd.service
Dica
Dica: nmbd Opcional

Se você não precisa de navegação em rede, não é necessário habilitar e iniciar o serviço nmbd em um membro do domínio Unix.

20.2.10 Testando a conectividade de winbindd

20.2.10.1 Enviand 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:

cephadm@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.

20.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”:

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

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

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

20.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:

cephadm@smb > chown "DOMAIN\\demo01:DOMAIN\\domain users" file.txt
Imprimir esta página