Quando o Samba 3 foi lançado, Samba na rede. Análise

Transcrição

1 Análise Samba na rede Desde o lançamento da versão final, o Samba 4 tem se tornado bastante significativo no dia a dia da TI; agora ele encontrou um caminho no Jessie, o próximo lançamento Debian. Analisamos os novos recursos neste artigo. por Michael Ziegler Quando o Samba 3 foi lançado, em 2003, consistia em três serviços: o servidor de arquivos smbd, o servidor de nomes nmbd e o servidor de autenticação winbind. Em sua interação com o resto do sistema, esses três serviços forneciam um serviço de arquivo e um controlador de domínio NT4. O desenvolvimento do Samba 4 [1] mudou completamente essa estrutura. O suporte do Samba 4 para um domínio Active Directory significava que ele precisaria fornecer uma ampla gama de serviços: a resolução de nomes clássica NE- TBIOS foi substituída pelo DNS, a autenticação foi centralizada usando Kerberos e o armazenamento de dados centralizado foi implementado via LDAP somente o servidor de arquivos continua a ser o mesmo, com alterações para corresponder à nova estrutura. Pela primeira vez, é possível agora usar o Samba 4 para mapear uma estrutura completa de domínio do Windows no Linux. Os pacotes Debian do Samba oferecem essa possibilidade e solicitam, no momento da instalação, que o usuário decida a função que o sistema irá desempenhar em sua rede. Provisionamos quatro sistemas no laboratório: uma máquina virtual como um controlador de domínio (Debian Jessie 58

2 [2]), um sistema openattic [3] como um membro do domínio (Debian Jessie), e dois clientes Windows como membros de domínio (Windows 7/8). O sistema de arquivos de rede está mais integrado do que nunca ao conceito de domínio usá-lo sem o gerenciamento de usuários e permissões no domínio faz pouco sentido. A configuração descrita neste artigo é, portanto, um requisito básico para o uso do Samba como um sistema de arquivos compartilhado na empresa. Listagem 1: Processos no Samba 4 root@dev mz s4dc:~# netstat tupl grep samba tcp 0 0 *:kpasswd *:* LISTEN 4908/samba tcp 0 0 *:domain *:* LISTEN 4914/samba tcp 0 0 *:kerberos *:* LISTEN 4908/samba tcp 0 0 *:ldaps *:* LISTEN 4906/samba tcp 0 0 *:1024 *:* LISTEN 4902/samba tcp 0 0 *:3268 *:* LISTEN 4906/samba tcp 0 0 *:3269 *:* LISTEN 4906/samba tcp 0 0 *:ldap *:* LISTEN 4906/samba tcp 0 0 *:loc srv *:* LISTEN 4902/samba udp 0 0 *:kpasswd *:* 4908/samba udp 0 0 *:domain *:* 4914/samba udp 0 0 *:kerberos *:* 4908/samba udp 0 0 *:netbios ns *:* 4904/samba udp 0 0 *:netbios dgm *:* 4904/samba udp 0 0 *:ldap *:* 4907/samba Controlador de domínio O novo Samba é um sistema modular (listagem 1) que permite terceirizar diversos serviços relacionados ao Active Directory; por exemplo, podemos substituir o DNS com bind9 ou com um serviço de diretório OpenLDAP. Um serviço central que fornece o controlador de domínio (DC) é fácil de ignorar: um domínio do Windows lida com a autenticação completa via Kerberos. O Kerberos só funciona se todos os sistemas mantiverem o tempo com um intervalo de não mais do que cinco minutos um do outro. Portanto, é essencial para configurar um servidor NTP para evitar problemas de tempo. A instalação do software do controlador de domínio é fácil de fazer usando o comando apt-get install samba. O Debconf surge durante a instalação com perguntas sobre a função do servidor e os dados-chave do domínio e também lida com o provisionamento automaticamente. O ideal é que o usuário não precise fazer nada sozinho. Se algo der errado, o reprovisionamento com samba tool domain provision é facilmente possível. Os pacotes também garantem que o samba tool use os valores corretos. Entre outros arquivos, o processo de provisionamento produz tanto os arquivos /etc/krb5. conf como /etc/samba/smb.conf, que se parece com a listagem 2 quando concluído. Essa configuração inclui tudo que o que o usuário precisa para começar a trabalhar. Instalação do membro do domínio O usuário precisa estar ciente de uma restrição à execução do servidor Samba 4 como um Listagem 2: /etc/samba/ smb.conf 01 # Global parameters 02 [global] 03 workgroup = SAMBA 04 realm = SAMBA.LAN 05 netbios name = DEV MZ S4DC 06 server role = active directory domain controller 07 dns forwarder = [netlogon] 10 path = /var/lib/samba/ sysvol/samba.lan/scripts 11 read only = No [sysvol] 14 path = /var/lib/samba/sysvol 15 read only = No membro do domínio: o programa samba não suporta a operação como um membro do domínio. Essa configuração é assim implementada usando os programas smbd, nmbd e winbind. Neste ponto, lembre-se do cliente NTP, que definitivamente precisa ser configurado na frente: se o tempo não estiver sincroniza- Listagem 3: /etc/samba/smb. conf para openattic 01 [global] 02 workgroup = SAMBA 03 realm = SAMBA.LAN 04 netbios name = BENRIME 05 security = ADS encrypt passwords = true 08 vfs objects = acl_xattr kerberos method = dedicated keytab 11 dedicated keytab file = /etc/krb5. keytab idmap config *:backend = tdb 14 idmap config *:range = idmap config SAMBA:backend = rid 17 idmap config SAMBA:range = winbind nss info = rfc winbind trusted domains only = no 21 winbind use default domain = yes 22 winbind enum users = no 23 winbind enum groups = no 24 template shell = /bin/bash sync always = yes Linux Magazine #115 Outubro de

3 Listagem 4: Autenticação Kerberos kinit Administrator Password for klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: Valid starting Expires Service principal :58: :58:27 renew until :58:24 Listagem 5: Kerberos Keytab net ads join U Administrator Password: root@benrime:~$ net ads keytab create # Generate keytab root@benrime:~$ net ads keytab add HTTP # Principally used for HTTP root@benrime:~$ kdestroy # Log out administrator root@benrime:~$ klist k # Display generated keytab Keytab name: FILE:/etc/krb5.keytab KVNO Principal 2 host/benrime.samba.lan@samba.lan 2 host/benrime.samba.lan@samba.lan 2 host/benrime.samba.lan@samba.lan 2 host/benrime@samba.lan 2 host/benrime@samba.lan 2 host/benrime@samba.lan 2 BENRIME$@SAMBA.LAN 2 BENRIME$@SAMBA.LAN 2 BENRIME$@SAMBA.LAN 2 HTTP/benrime.samba.lan@SAMBA.LAN 2 HTTP/benrime.samba.lan@SAMBA.LAN 2 HTTP/benrime.samba.lan@SAMBA.LAN 2 HTTP/benrime@SAMBA.LAN 2 HTTP/benrime@SAMBA.LAN 2 HTTP/benrime@SAMBA.LAN root@benrime:~$ # Log in using Keytab + machine account: root@benrime:~$ kinit k BENRIME$ root@benrime:~$ # Keytab Auth > no password prompt! root@benrime:~$ klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: BENRIME$@SAMBA.LAN Valid starting Expires Service principal :05:26 AM :05:26 PM krbtgt/samba.lan@ SAMBA.LAN renew until :05:26 AM do, o usuário não poderá contar com uma instalação do Samba em funcionamento. Além disso, precisa verificar se o hostname --fqdn retorna o nome completo e correto do computador: $ hostname fqdn benrime.samba.lan No laboratório, queríamos que o servidor de armazenamento openattic atuasse como um membro do domínio. Para fazer isso, instalamos o Debian Wheezy no computador, depois configuramos o openattic no sistema e, finalmente, atualizamos para o Debian Jessie. O sistema é então como previsto pelo padrão openattic adicionado ao domínio usando o comando oaconfig domainjoin. O script executa uma série de comandos que são descritos detalhadamente mais tarde, e deve funcionar em qualquer sistema Linux. O OpenATTIC primeiro cria o arquivo krb5.conf (isso também pode ser copiado do DC) e a configuração do Samba /etc/ samba/smb.conf (listagem 3). Em seguida, o openattic testa se o Kerberos está funcionando, ao autenticar-se como administrador (listagem 4). Se essa etapa for bem-sucedida, utilize net ads join U Administrator para acessar o domínio. A configuração do Samba para openattic usa um keytab externo para ativar a autenticação Kerberos para outros serviços além do Samba. é por isso que o usuário precisa gerar e validar o keytab (listagem 5). Se tudo deu certo, a associação de domínio já estará concluída. A tarefa final é configurar o winbind, modificando o arquivo /etc/ nsswitch.conf da seguinte forma: passwd: compat winbind group: compat winbind Após um reboot subsequente do servidor Winbind (com o comando service winbind restart), o novo membro do domínio pode acessar o domínio e recuperar usuários e grupos: root@benrime:~$ getent passwd Administrator administrator:*:10500:10513: Administrator:/home/SAMBA/ administrator:/bin/bash root@benrime:~$ getent group "Domain Admins" 60

4 Figura 1 Com a configuração correta, os clientes Windows podem ingressar em um domínio Samba 4. domain admins:x:10512:test, administrator Isso completa o processo de inclusão de domínio. Sistemas Windows ingressam em um domínio Samba 4 como um Windows Active Directory clássico (figura 1). Para fazer isso, navegue pelas configurações do sistema até Advanced System Settings/Computer Name/Change (Configurações Avançadas do Sistema/Nome do Computador/Alteração), em seguida, insira o nome de domínio, responda ao prompt com a senha do administrador e depois de alguns segundos de espera e de um reboot, estará apto a ingressar no domínio. O Windows atualiza automaticamente a configuração do cliente NTP na adesão. Figura 2 O Windows utiliza um conceito de autorização complexo, finamente granular. Administração do domínio Para gerenciar o novo domínio, podemos usar as ferramentas clássicas de gerenciamento do Windows. Essas são incluídas como parte de qualquer sistema operacional atual do servidor Windows, mas também estão disponíveis como um pacote instalável retroativamente para clientes Windows 7 e Windows 8 sob o nome Remote Server Administration Tools (Ferramentas Remotas do Servidor de Administração) [4]. Novos usuários podem ser criados, por exemplo, em Active Directory Users and Computers (Usuários e Computadores do Listagem 6: ACLs $ getfacl /tank/herbert/ # file: tank/herbert/ # owner: test # group: domain\040users user::rwx user:otto:r user:herbert:rwx group::r x mask::rwx other::r x default:user::rwx default:user:otto:r default:user:herbert:rwx default:group::r x default:mask::rwx default:other::r x Active Directory). O bom e velho Samba Web Administration Tool (SWAT) infelizmente já não corresponde mais ao conceito Samba 4 e morreu junto com o Samba 3. Atualmente, não há um substituto, portanto as únicas ferramentas de administração são aquelas fornecidos pelo Windows. No entanto, o Samba 4 fornece uma API Python para Listagem 7: Atributos estendidos $ touch /tank/test $ setfattr n user.myvalue v "Hello World" /tank/test $ getfattr d /tank/test # file: tank/test user.myvalue="hello World" $ getfattr n user.myvalue / tank/test # file: tank/test user.myvalue="hello World" $ getfattr only values n user.myvalue /tank/test Hello World Linux Magazine #115 Outubro de

5 Tabela 1 Sistemas de arquivos backend Sistema de arquivos ACLs Cotas Shrink Compressão Deduplicação Snapshots Redundância Distribuído Tamanho máximo ext4 Sim Sim Sim Não Não Não Não Não 1EiB XFS Sim Sim Não Não Não Não Não Não 16EiB ZFS no Linux Não Sim Sim Sim Sim Sim Sim Não 16EiB Btrfs Sim Sim Sim Sim Não Sim Sim Não 16EiB OCFS2 Sim Sim Sim Não Não Sim Sim Sim 4PiB GlusterFS Sim Sim Sim Sim* Sim* Não Sim Sim Ceph Sim Sim Sim Sim* Sim* Não Sim Sim *Depende do sistema de arquivos subjacente simplificar o desenvolvimento dessas ferramentas. Após a criação de dois usuários, herbert e otto, testamos se o openattic já os havia localizado: root@benrime:~$ getent passwd herbert herbert:*:11110:10513::/home/ SAMBA/herbert:/bin/bash root@benrime:~$ getent passwd otto otto:*:11109:10513::/home/ SAMBA/otto:/bin/bash Isso é uma boa notícia. Esses usuários podem logar em clientes do Windows a partir de agora. Em seguida, o usuário pode criar um volume e um compartilhamento CIFS no openattic. Isso acontece em smb.conf, por exemplo, ao se adicionar uma nova seção: [tank] path = /tank available = yes browseable = yes guest ok = no writeable = yes Note que não mencionamos nada sobre permissões até agora. Elas são configuradas completamente pelo administrador no Windows ao abrir o compartilhamento no Windows Explorer e conceder as permissões. Para que isso funcione corretamente, são necessárias duas coisas: um sistema de arquivos com suporte para atributos estendidos e a linha vfs objects = acl_xattr no arquivo smb.conf do host de armazenamento. Permissões O Windows suporta uma variedade de permissões que podem ser atribuídas de forma granular para as ações, pastas e arquivos que elas contêm (figura 2), enquanto que o Linux apenas suporta permissões Read, Write e Execute (ler, escrever e executar) para o dono, grupo e o restante das funções. Do ponto de vista de um administrador do Windows, isso não é um gerenciamento adequado de direitos. Conectar esses dois mundos, portanto, não é simples, mas necessário. Se o Samba não for a única maneira de acessar os dados (por exemplo, com login local ou com compartilhamento NFS no servidor), o usuário deve certificar-se de que os direitos de acesso definidos não podem ser contornados localmente. Em outras palavras, não basta simplesmente salvar as permissões em um banco de dados; o usuário também precisa incluir o sistema de arquivos Linux. As primeiras versões do Samba convertiam as permissões do Windows para parâmetros Linux e ignoravam outras configurações de controle de acesso. Essa solução é, obviamente, insatisfatória, por isso, o próximo passo é suportar POSIX ACLs. Isso significa que há, pelo menos, a possibilidade de atribuir permissões especificamente para usuários individuais (mesmo que não seja o proprietário) e grupos individuais (listagem 6). Essa abordagem é um passo à frente, mas, infelizmente, ainda não é o suficiente: o Windows não suporta apenas leitura, escrita e execução, mas também permissões incomuns, como excluir subpastas e arquivos, mas não a pasta em si. Essas permissões não podem ser mapeadas no sistema de arquivos no Linux atualmente. No entanto, é importante manter e implementá-las no mundo Win- 62

6 dows, pelo menos. Para fazer isso, o Samba utiliza atributos avançados de arquivo, os quais permitem que as variáveis arbitrárias sejam associadas ao arquivo em determinados namespaces (listagem 7). Os atributos estendidos, portanto, oferecem a possibilidade de armazenar metadados arbitrários para um arquivo. O Samba (ou, mais precisamente, o módulo vfs_acl_xattr) agora utiliza esses recursos para salvar as permissões que não podem ser mapeadas: $ getfattr n security.ntacl /tank/herbert/ # file: tank/herbert/ security. NTACL=0sAwADAAAAAgAEAAI... Uma questão menor existe aqui, no entanto: nem todos os sistemas de arquivos suportam esses mecanismos; em particular, o ZFS no Linux não os surpota. No Solaris e no FreeBSD, o módulo vfs_zfsacl oferece uma saída, mas não está disponível no Linux. Podemos contornar isso com o módulo vfs_acl_tdb, que armazena as permissões em um arquivo de banco de dados. Esse módulo também fornece uma opção para modificar as ACLs POSIX; assim, dada uma configuração cuidadosa, não devem ser esperados problemas no caso de acesso por terceiros. No entanto, essa solução e o uso de atributos estendidos não são escalonáveis, porque o acesso ao banco de dados pode rapidamente tornar-se um problema de desempenho. Além disso, os snapshots, a alta disponibilidade e o failover não são tão fáceis de implementar. Se o usuário precisa de recursos, como os oferecidos pelo ZFS, deverá considerar o uso do Btrfs. Matrix de recursos A seleção do sistema de arquivos no servidor de armazenamento tem um efeito adicional sobre as funções que um servidor de arquivos pode oferecer aos usuários, além de suporte para ACLs. Qual destes fatores é relevante na prática, claro, depende sempre da empresa e do tipo de dados armazenados. Outras funções interessantes incluem: Cotas: o sistema de arquivos permite definir limites de tamanho dos diretórios para usuários individuais e grupos. Filesystem shrink: o sistema de arquivos tanto pode encolher como crescer. Se o usuário calcular mal a configuração de armazenamento, a correção depois será fácil, sem a necessidade de remoção dos dados. Compressão: o sistema de arquivos suporta a compressão de dados antes de serem armazenados e pode, portanto, usar o espaço disponível de forma mais eficaz. Deduplicação: o sistema de arquivos detecta os blocos de dados duplicados e armazena-os apenas uma vez, então é preciso usar o espaço disponível da forma mais eficiente. Snapshots: o sistema de arquivos suporta a capacidade de Gostou do artigo? Queremos ouvir sua opinião. Fale conosco em: cartas@linuxmagazine.com.br Este artigo no nosso site: Mais informações [1] Samba 4: [2] Debian Jessie: [3] openattic: attic.org/en/home.html criar subvolumes e snapshots. Dessa forma, toda a árvore de diretório ou sub-árvore pode ser congelada em questão de segundos para que seu estado não se altere mais. Redundância: o próprio sistema de arquivos oferece a possibilidade de armazenamento de dados redundantes de modo que a falha de um disco rígido possa ser compensada de maneira invisível ao usuário. Não há necessidade de recorrer à RAID. Distribuído: sistemas de arquivos distribuídos e de cluster como o OCFS2 ou Ceph oferecem diferentes maneiras de olhar para armazenamento em vários hosts como uma única grande área de armazenamento. Os dados são armazenados e distribuídos de forma redundante nesses hosts para compensar a incapacidade dos hosts individuais de uma maneira que seja transparente para o usuário. Uma visão geral dos sistemas de arquivos de back-end usados no Samba para esses contextos é fornecida na tabela 1. Oferecer uma recomendação geral a favor ou contra um sistema de arquivos individuais não faz sentido, por ser conduzido pelo uso pretendido do usuário e pelo crescimento esperado dos dados. n [4] Remote Server Administration Tools: en us/download/details.aspx?id=28972 Linux Magazine #115 Outubro de