58 www.linuxmagazine.com.br

Samba na redeDesde 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 servi-

dor de arquivos smbd, o servidor de nomes nmbd e o servidor de autenticação winbind. Em sua in-teração com o resto do sistema, esses três serviços forneciam um serviço de arquivo e um controla-dor de domínio NT4. O desenvol-vimento do Samba 4 [1] mudou completamente essa estrutura. O suporte do Samba 4 para um

domínio Active Directory signifi-cava 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 armazena-mento 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 ma-pear uma estrutura completa de domínio do Windows no Linux. Os pacotes Debian do Samba ofere-cem essa possibilidade e solici-tam, no momento da instalação, que o usuário decida a função que o sistema irá desempenhar em sua rede. Provisionamos qua-tro sistemas no laboratório: uma máquina virtual como um contro-lador de domínio (Debian Jessie

Análise

59Linux Magazine #115 | Outubro de 2014

[2]), um sistema openATTIC [3] como um membro do domínio (Debian Jessie), e dois clientes Windows como membros de do-mínio (Windows 7/8). O sistema de arquivos de rede está mais integrado do que nunca ao con-ceito 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 re-quisito básico para o uso do Sam-ba como um sistema de arquivos compartilhado na empresa.

Controlador de domínioO novo Samba é um sistema modular (listagem 1) que permite terceirizar diversos serviços re-lacionados ao Active Directory; por exemplo, podemos substi-tuir 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 auten-ticação completa via Kerberos. O Kerberos só funciona se to-dos 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 automatica-mente. O ideal é que o usuário não precise fazer nada sozinho. Se algo der errado, o reprovisio-namento 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 quan-do 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ínioO usuário precisa estar ciente de uma restrição à execução do servidor Samba 4 como um

membro do domínio: o progra-ma samba não suporta a operação como um membro do domínio. Essa configuração é assim imple-mentada usando os programas smbd, nmbd e winbind. Neste pon-to, lembre-se do cliente NTP, que definitivamente precisa ser configurado na frente: se o tempo não estiver sincroniza-

Listagem 1: Processos no Samba 4root@dev‑mz‑s4dc:~# netstat ‑tupl | grep sambatcp 0 0 *:kpasswd *:* LISTEN 4908/sambatcp 0 0 *:domain *:* LISTEN 4914/sambatcp 0 0 *:kerberos *:* LISTEN 4908/sambatcp 0 0 *:ldaps *:* LISTEN 4906/sambatcp 0 0 *:1024 *:* LISTEN 4902/sambatcp 0 0 *:3268 *:* LISTEN 4906/sambatcp 0 0 *:3269 *:* LISTEN 4906/sambatcp 0 0 *:ldap *:* LISTEN 4906/sambatcp 0 0 *:loc‑srv *:* LISTEN 4902/sambaudp 0 0 *:kpasswd *:* 4908/sambaudp 0 0 *:domain *:* 4914/sambaudp 0 0 *:kerberos *:* 4908/sambaudp 0 0 *:netbios‑ns *:* 4904/sambaudp 0 0 *:netbios‑dgm *:* 4904/sambaudp 0 0 *:ldap *:* 4907/samba

Listagem 2: /etc/samba/ smb.conf01 # Global parameters02 [global]03 workgroup = SAMBA04 realm = SAMBA.LAN05 netbios name = DEV‑MZ‑S4DC06 server role = active directory domain controller07 dns forwarder = 172.16.101.230809 [netlogon]10 path = /var/lib/samba/sysvol/samba.lan/scripts11 read only = No1213 [sysvol]14 path = /var/lib/samba/sysvol15 read only = No

Listagem 3: /etc/samba/smb.conf para openATTIC01 [global]02 workgroup = SAMBA03 realm = SAMBA.LAN04 netbios name = BENRIME05 security = ADS0607 encrypt passwords = true08 vfs objects = acl_xattr0910 kerberos method = dedicated keytab11 dedicated keytab file = /etc/krb5.keytab1213 idmap config *:backend = tdb14 idmap config *:range = 1000000‑19999991516 idmap config SAMBA:backend = rid17 idmap config SAMBA:range = 10000‑9999991819 winbind nss info = rfc230720 winbind trusted domains only = no21 winbind use default domain = yes22 winbind enum users = no23 winbind enum groups = no24 template shell = /bin/bash2526 sync always = yes

60 www.linuxmagazine.com.br

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 armazena-mento 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, atuali-zamos para o Debian Jessie. O sistema é então – como pre-visto 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 tam-bém pode ser copiado do DC) e a configuração do Samba /etc/samba/smb.conf (listagem 3). Em se-guida, o openATTIC testa se o Kerberos está funcionando, ao autenticar-se como administra-dor (listagem 4). Se essa etapa for bem-sucedida, utilize net ads join ‑U Administrator para acessar o do-mí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 win‑bind, 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 co-mando 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"

Listagem 5: Kerberos Keytabroot@benrime:~$ net ads join ‑U AdministratorPassword:root@benrime:~$ net ads keytab create # Generate keytabroot@benrime:~$ net ads keytab add HTTP # Principally used for HTTProot@benrime:~$ kdestroy # Log out administratorroot@benrime:~$ klist ‑k # Display generated keytab

Keytab name: FILE:/etc/krb5.keytabKVNO Principal2 host/benrime.samba.lan@SAMBA.LAN2 host/benrime.samba.lan@SAMBA.LAN2 host/benrime.samba.lan@SAMBA.LAN2 host/benrime@SAMBA.LAN2 host/benrime@SAMBA.LAN2 host/benrime@SAMBA.LAN2 BENRIME$@SAMBA.LAN2 BENRIME$@SAMBA.LAN2 BENRIME$@SAMBA.LAN2 HTTP/benrime.samba.lan@SAMBA.LAN2 HTTP/benrime.samba.lan@SAMBA.LAN2 HTTP/benrime.samba.lan@SAMBA.LAN2 HTTP/benrime@SAMBA.LAN2 HTTP/benrime@SAMBA.LAN2 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:~$ klistTicket cache: FILE:/tmp/krb5cc_0Default principal: BENRIME$@SAMBA.LAN

Valid starting Expires Service principal06.02.2014 10:05:26 AM 06.02.2014 8:05:26 PM krbtgt/SAMBA.LAN@SAMBA.LAN renew until 07.02.2014 10:05:26 AM

Listagem 4: Autenticação Kerberosroot@benrime:~$ kinit AdministratorPassword for Administrator@SAMBA.LAN:root@benrime:~$ klistTicket cache: FILE:/tmp/krb5cc_0Default principal: Administrator@SAMBA.LAN

Valid starting Expires Service principal06.02.2014 11:58:27 06.02.2014 21:58:27 krbtgt/SAMBA.LAN@SAMBA.LAN renew until 07.02.2014 11:58:24

61Linux Magazine #115 | Outubro de 2014

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 configu-rações do sistema até Advan‑ced 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 Windo-ws atualiza automaticamente a configuração do cliente NTP na adesão.

Administração do domínioPara 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 Win-

dows, mas também estão dispo-níveis como um pacote instalável retroativamente para clientes Windows 7 e Windows 8 sob o nome ”Remote Server Administra‑tion 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

Active Directory). O bom e ve-lho 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 úni-cas ferramentas de administra-ção são aquelas fornecidos pelo Windows. No entanto, o Samba 4 fornece uma API Python para

Figura 1 Com a configuração correta, os clientes Windows podem ingressar em um domínio Samba 4.

Figura 2 O Windows utiliza um concei-to de autorização complexo, finamen-te granular.

Listagem 6: ACLs$ getfacl /tank/herbert/# file: tank/herbert/# owner: test# group: domain\040usersuser::rwxuser:otto:r‑‑user:herbert:rwxgroup::r‑xmask::rwxother::r‑xdefault:user::rwxdefault:user:otto:r‑‑default:user:herbert:rwxdefault:group::r‑xdefault:mask::rwxdefault:other::r‑x

Listagem 7: Atributos estendidos$ touch /tank/test$ setfattr ‑n user.myvalue ‑v "Hello World" /tank/test$ getfattr ‑d /tank/test# file: tank/testuser.myvalue="Hello World"

$ getfattr ‑n user.myvalue /tank/test# file: tank/testuser.myvalue="Hello World"$ getfattr ‑‑only‑values ‑n user.myvalue /tank/testHello World

62 www.linuxmagazine.com.br

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 comple-tamente pelo administrador no Windows ao abrir o compartilha-

mento no Windows Explorer e conceder as permissões. Para que isso funcione corretamen-te, são necessárias duas coisas: um sistema de arquivos com su-porte para atributos estendidos e a linha vfs objects = acl_xat‑tr no arquivo smb.conf do host de armazenamento.

PermissõesO Windows suporta uma varie-dade de permissões que podem ser atribuídas de forma granular para as ações, pastas e arqui-vos que elas contêm (figura 2), enquanto que o Linux apenas suporta permissões Read, Write e Execute (ler, escrever e exe-cutar) para o dono, grupo e o restante das funções. Do ponto de vista de um administrador do Windows, isso não é um geren-ciamento 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 sim-plesmente 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 Sam-ba convertiam as permissões do Windows para parâmetros Linux e ignoravam outras confi-gurações de controle de acesso. Essa solução é, obviamente, in-satisfatória, por isso, o próximo passo é suportar POSIX ACLs. Isso significa que há, pelo me-nos, a possibilidade de atribuir permissões especificamente para usuários individuais (mes-mo 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, es-crita 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 ar-quivos no Linux atualmente. No entanto, é importante manter e implementá-las no mundo Win-

Sistema de arquivos

ACLs Cotas ShrinkCom-

pressãoDedupli-

caçãoSnap-shots

Redun-dância

Distri- buí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

Tabela 1 Sistemas de arquivos backend

63Linux Magazine #115 | Outubro de 2014

Mais informações

[1] Samba 4: https://www.samba.org/

[2] Debian Jessie: http://www.debian.org/releases/testing/

[3] openATTIC: http://www.open‑attic.org/en/home.html

[4] Remote Server Administration Tools: http://www.microsoft.com/en‑us/download/details.aspx?id=28972

dows, pelo menos. Para fazer isso, o Samba utiliza atributos avançados de arquivo, os quais permitem que as variáveis arbi-trárias sejam associadas ao ar-quivo em determinados names‑paces (listagem 7). Os atributos estendidos, portanto, oferecem a possibilidade de armazenar metadados arbitrários para um arquivo. O Samba (ou, mais pre-cisamente, o módulo vfs_acl_xat‑tr) 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 arma-zena as permissões em um ar-quivo de banco de dados. Esse módulo também fornece uma opção para modificar as ACLs POSIX; assim, dada uma confi-guraçã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 recur-sos, como os oferecidos pelo ZFS, deverá considerar o uso do Btrfs.

Gostou do artigo?Queremos ouvir sua opinião. Fale conosco em: cartas@linuxmagazine.com.br

Este artigo no nosso site: http://lnm.com.br/article/9672

Matrix de recursosA 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 tama-nho dos diretórios para usuários individuais e grupos.

➧ Filesystem shrink: o sistema de arquivos tanto pode encolher como crescer. Se o usuário calcu-lar mal a configuração de arma-zenamento, 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 arma-zenados 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 for-ma mais eficiente.

➧ Snapshots: o sistema de ar-quivos suporta a capacidade de

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 sis-tema de arquivos oferece a pos-sibilidade de armazenamento de dados redundantes de modo que a falha de um disco rígido possa ser compensada de maneira invi-sível ao usuário. Não há necessi-dade de recorrer à RAID.

➧ Distribuído: sistemas de ar-quivos 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 pretendi-do do usuário e pelo crescimento esperado dos dados. n