samba parte 2

Samba, parte 2: Configurao avanada do Samba (atualizado)


http://www.guiadohardware.net/tutoriais/samba-configuracao-avancada/Tutoriais

Na primeira parte do tutorial, falei sobre a instalao do Samba, cadastro dos usurios e sobre a configurao usando o swat. Nesta segunda parte mergulharemos na configurao manual do Samba, editando diretamente o arquivo smb.conf, mostrando detalhes sobre as opes e apresentando exemplos de configurao funcionais.Carlos E. Morimoto24/06/2009Clique aqui para ver a primeira parteComo vimos na primeira parte do tutorial, a maior parte da configurao do Samba, incluindo as configuraes gerais do servidor, impressoras e todos os compartilhamentos, feita em um nico arquivo de configurao, o "/etc/samba/smb.conf". Programas de configurao, como o Swat, simplesmente lem este arquivo, "absorvem" as configuraes atuais e depois geram o arquivo novamente com as alteraes feitas dentro da interface. Isso permite que o Swat coexista com a edio manual do arquivo. Como comentei a pouco, o Swat remove todos os seus comentrios e formatao (deixando apenas as opes), por isso muitos evitam us-lo.

Apesar disso, o formato do arquivo de configurao do Samba bastante simples e por isso muitas vezes mais rpido e at mais simples editar diretamente o arquivo do que faz-lo atravs do Swat. Ao instalar o Samba, criado um arquivo de configurao de exemplo, com vrios comentrios. Assim como no caso do Squid, ele longo e difcil de entender, por isso acaba sendo mais fcil renome-lo e comear com um arquivo em branco, ou usar como base a configurao gerada atravs do Swat.

Vamos ento a uma segunda rodada de explicaes sobre a configurao do Samba, agora editando diretamente o arquivo smb.conf e explorando com maior profundidade as opes disponveis. Vamos comear com um exemplo simplista, onde temos um nico compartilhamento de teste:

[global]

netbios name = Sparta

workgroup = Grupo

[arquivos]

path = /mnt/arquivos

comment = Teste

Como voc pode ver, o arquivo dividido em sees. A primeira sempre a seo "[global]", que contm as opes gerais do servidor. Por enquanto, definimos apenas o nome do servidor (netbios name) e o nome do grupo de trabalho (workgroup), que seria o mnimo necessrio para colocar o servidor na rede. As demais opes (no especificadas no arquivo) so configuradas usando os valores default. Se voc omitir a opo "workgroup", por exemplo, o Samba vai reverter para o grupo "WORKGROUP", que o padro.

Se quiser, voc pode tambm adicionar uma descrio para o servidor, o que feito atravs da opo "server string" (adicionada dentro da seo [global]), como em:

server string = Servidor Samba

Duas dicas so que:

a) O default do Samba usar a string "Samba 3.0.24" (onde o "3.0.24" a verso usada) como descrio quando a opo "server string" no est presente no arquivo.

b) Nas mquinas com o Windows XP, a descrio do servidor aparece antes do nome propriamente dito, como em "Servidor Samba (Sparta)". importante levar isso em considerao, j que, no final das contas, o que importa o que os usurios iro ver ao navegar pelo ambiente de redes:

Abaixo da seo [global], inclumos sees adicionais para cada compartilhamento, que o caso da seo "[arquivos]" que cria o compartilhamento de teste.

O "[arquivos]" indica o nome do compartilhamento, da forma como ele aparecer na rede. Logo a seguir temos a linha "path", que diz qual pasta do servidor ser compartilhada e a linha "comment" (opcional), que permite que voc inclua um comentrio.

Sempre que alterar manualmente o smb.conf, ou mesmo alterar algumas opes pelo Swat e quiser verificar se as configuraes esto corretas, rode o comando testparm. Ele funciona como uma espcie de debug, indicando erros grosseiros no arquivo e informando o papel do servidor na rede:

# testparm

Load smb config files from /etc/samba/smb.conf

Processing section "[arquivos]"

Loaded services file OK.

Server role: ROLE_STANDALONE

O "ROLE_STANDALONE" significa que o servidor foi configurado como um membro normal do grupo de trabalho. possvel tambm fazer com que o servidor Samba atue como um controlador de domnio, como veremos em detalhes mais adiante.

Em caso de erros no arquivo, o testparm ajuda a localizar o problema, indicando a linha ou opo invlida, de forma que voc possa corrig-la. Veja o que acontece ao adicionar um erro simples, usando a linha "wrritable = yes" no lugar de "writable = yes":

Unknown parameter encountered: "wrritable"

Ignoring unknown parameter "wrritable"

O Samba no diferencia o uso de maisculas e minsculas nas opes, de forma que tanto faz escrever "writable = yes", "writable = Yes" ou "writable = YES". Entretanto, muitos dos parmetros no so diretamente usados pelo Samba, mas sim repassados ao sistema que, diferentemente do Samba, diferencia os caracteres. Um exemplo so as localizaes de pastas a compartilhar. Se voc escrever "path = /mnt/Arquivos" (em vez de "path = /mnt/arquivos"), o compartilhamento no vai funcionar, pois o sistema reportar que a pasta no existe.

Alm do caractere "#", possvel usar tambm o ";" para comentar linhas. A principal observao que voc no pode inserir comentrios em linhas vlidas (mesmo que no final da linha), pois, ao fazer isso, toda a linha passa a ser ignorada pelo Samba. Neste exemplo, o comentrio foi includo na linha "path", o que acaba por desativar o compartilhamento completamente:

[teste]

path = /mnt/arquivos # Pasta compartilhada

comment = Compartilhamento que no funciona

O testparm tambm no indica o erro diretamente, j que ele tambm considera a linha como um comentrio, o que pode lev-lo a perder um bom tempo tentando descobrir onde est o problema. Ao incluir comentrios no arquivo, use sempre linhas separadas:

[teste]

# Pasta compartilhada


comment = Agora sim

As alteraes no arquivo so lidas periodicamente pelo Samba (o default so 3 minutos) e aplicadas automaticamente. Isso permite que as mudanas de configurao sejam aplicadas de forma suave, sem prejudicar o acesso dos usurios, o que importante em um ambiente de produo. Para fazer com que as alteraes entrem em vigor imediatamente, reinicie o servio do Samba, como em:

# /etc/init.d/samba restart

ou:

# service smb restart

A partir da, o compartilhamento estar disponvel. Ao tentar acessar o servidor atravs do "Meus locais de rede" nos clientes Windows, voc receber um prompt de senha, onde voc precisa fornecer um dos logins cadastrados no servidor usando o comando "smbpasswd -a":

importante enfatizar que todos os usurios cadastrados no Samba precisam tambm existir no sistema, por isso, antes de usar o comando "smbpasswd -a", voc deve usar o adduser para criar o usurio. Como citei anteriormente, a soluo para casos em que voc no deseja criar contas vlidas para todos os usurios criar usurios limitados usando o comando "adduser --disabled-login --no-create-home usuario" ou "adduser -M usuario".

Depois de logado, o cliente pode visualizar os compartilhamentos do servidor. Por enquanto temos apenas o compartilhamento "arquivos", que mostra o contedo da pasta "/mnt/arquivos" do servidor, mas ao longo do tutorial adicionaremos muitos outros recursos ao servidor:

Ajustando as permisses de acesso


Carlos E. Morimoto24/06/2009Com esta configurao, os clientes conseguem visualizar os arquivos da pasta normalmente, mas ainda no conseguem gravar nos arquivos. Ao tentar salvar alguma coisa na pasta, voc recebe uma mensagem de acesso negado:

Isso acontece por dois motivos. O primeiro que o default do Samba compartilhar com permisso apenas para leitura. Como no dissemos nada sobre as permisses de acesso do compartilhamento no arquivo de configurao, ele foi compartilhado usando o default.

Para que o compartilhamento fique disponvel com permisso de leitura e escrita, precisamos adicionar a opo "writable = yes" dentro da configurao do compartilhamento, que ficar:

[arquivos]


writable = yescomment = Teste

Muito provavelmente, mesmo depois de reiniciar o Samba voc continuar recebendo o mesmo erro ao tentar gravar os arquivos. Dessa vez, o Samba autoriza a gravao, mas ela ainda pode ser abortada se as permisses da pasta no permitirem que o usurio grave arquivos. Se voc criou a pasta "/mnt/arquivos" como root, ento o default que apenas ele possa gravar arquivos na pasta. Para permitir que outros usurios possam gravar, necessrio abrir as permisses da pasta.

A esta altura, a lei do mnimo esforo diria para voc usar um:

# chmod 777 /mnt/arquivos

Obviamente, isso permitiria que os usurios gravassem na pasta. O problema que as permisses ficariam escancaradas, a ponto de qualquer um, que tenha acesso ao servidor (por qualquer meio) possa alterar os arquivos dentro da pasta, o que no nada bom do ponto de vista da segurana.

No tpico sobre o Swat, vimos como criar um grupo usando o users-admin (system-config-users) e abrir as permisses da pasta apenas para os usurios que fazem parte dele. Vamos ver agora como fazer isso via linha de comando.

O primeiro passo criar um grupo para os usurios que podero fazer alteraes na pasta, usando o comando "groupadd". Eu prefiro criar grupos com o mesmo nome do compartilhamento, para ficar mais fcil de lembrar, mas isso fica a seu critrio.

# groupadd arquivos

A partir da, voc pode adicionar usurios ao grupo usando o comando "adduser", nesse caso especificando o usurio j criado e o grupo ao qual ele ser adicionado, como em:

# adduser joao arquivos

# adduser maria arquivos

Para remover usurios do grupo, voc usa o comando "deluser", como em:

# deluser joao arquivos

# deluser maria arquivos

Depois de criar o grupo e adicionar os usurios a ele, falta apenas ajustar as permisses de acesso da pasta, de forma que o grupo tenha acesso completo, como em:

# chgrp arquivos /mnt/arquivos

# chmod 775 /mnt/arquivos

Com isso, trocamos o grupo dono da pasta e dizemos que tanto o dono quanto o grupo possuem acesso completo. A partir desse ponto, o Samba autoriza o acesso para todos os usurios cadastrados atravs do smbpasswd e o sistema autoriza a gravao para todos os usurios que fazem parte do grupo.

Se voc precisar que a alterao seja aplicada de forma recursiva, alterando as permisses de todas as subpastas e arquivos, adicione a opo "-R" nos dois comandos, como em:

# chgrp -R arquivos /mnt/arquivos

# chmod -R 775 /mnt/arquivos

Alm de servirem para controlar as permisses de acesso dos usurios s pastas do sistema, os grupos podem ser usados para ajustar as permisses de acesso do Samba, de forma bastante simples.

Se voc quer que o compartilhamento fique disponvel apenas para os usurios que cadastrou no grupo "arquivos", adicione a opo "valid users = +arquivos" na seo referente ao compartilhamento. O "+" indica que se trata de um grupo e no de um usurio isolado. O Samba verifica ento quais usurios fazem parte do grupo e autoriza o acesso. A partir da, quando voc quiser liberar o acesso para um novo usurio, basta adicion-lo ao grupo:

[arquivos]


writable = yes

valid users = +arquivosVoc pode tambm especificar uma lista de usurios isolados, separando-os por vrgula, por espao, ou pelos dois combinados (o que preferir), como em:

[arquivos]


writable = yes

valid users = joao, maria, jose possvel tambm combinar as duas coisas, indicando um ou mais grupos e tambm alguns usurios avulsos, como em:

[arquivos]


writable = yes

valid users = +arquivos, jose, joaquim, +adminAssim como na maioria das opes do Samba, a opo "valid users" exclusiva, ou seja, ao dizer que os usurios do grupo arquivos devem ter acesso, voc automaticamente exclui todos os outros. Voc pode tambm fazer o oposto, criando uma lista de usurios que no devem ter acesso e mantendo o acesso para os demais. Nesse caso, voc usaria a opo "invalid users", como em:

[arquivos]


writable = yes

invalid users = jose, joaquimNesse caso, todos os usurios cadastrados no Samba podem acessar, com exceo dos usurios jose e joaquim. possvel ainda usar a opo "invalid users" para especificar excees ao especificar grupos usando a opo "valid users", como em:

[arquivos]


writable = yes

valid users = +arquivosinvalid users = joaoNesse caso, todos os usurios dentro do grupo arquivos tero acesso, com exceo do joao. Esta combinao pode ser usada em casos onde o grupo especificado tambm em outros compartilhamentos e voc precisa bloquear o acesso do usurio a um compartilhamento especfico, sem remov-lo do grupo.

possvel tambm criar uma lista de escrita, usando a opo "write list". Ela cria uma camada adicional de proteo, permitindo que, dentro do grupo de usurios com acesso ao compartilhamento, apenas alguns tenham permisso para alterar os arquivos, como em:

[arquivos]


writable = novalid users = +arquivos

write list = mariaNesse caso, usamos a opo "writable = no", que faz com que o compartilhamento passe a ser somente-leitura. A seguir, especificamos que os usurios do grupo "arquivos" devem ter acesso (somente-leitura) e usamos a opo "write list = maria" para criar uma exceo, dizendo que a maria pode escrever na pasta. importante notar que, neste exemplo, a maria deve fazer parte do grupo "arquivos", caso contrrio teramos uma situao interessante, onde ela no consegue alterar os arquivos no compartilhamento, pois no tem acesso a ele em primeiro lugar. :)

Caso a maria no estivesse cadastrada no grupo, voc deveria incluir o login na opo "valid users", como em:

[arquivos]


writable = no

valid users = +arquivos, mariawrite list = maria

Podemos tambm fazer o oposto, restringindo a escrita para alguns usurios, mas mantendo o acesso para todos os demais. Nesse caso, usamos a opo "read list" para criar uma lista de excees, como em:

[arquivos]


writable = yesvalid users = +arquivos, +admin

read list = maria, joseNesse exemplo, usamos a opo "writable = yes" e especificamos que os usurios dentro dos grupos "arquivos" e "admin" tem acesso ao compartilhamento. Em seguida, usamos a opo "read list" para limitar o acesso dos usurios maria e jose, de forma que eles possam apenas ler, sem alterar os arquivos dentro da pasta.

Outra opo relacionada a "read only", que tambm aceita os valores "yes" e no". Na verdade, ela tem a mesma funo da opo "writable", apenas usa uma lgica invertida. Dizer "writable = yes" ou dizer "read only = no" tem exatamente o mesmo efeito, como seis e meia-dzia. Em geral, voc usa uma ou outra de acordo com o contexto, como uma forma de tornar o arquivo mais legvel, como em:

[modelos]

path = /mnt/modelos

read only = yesContinuando, possvel restringir o acesso tambm com base no endereo IP ou no nome da mquina a partir da qual o usurio est tentando acessar o compartilhamento. Isso permite adicionar uma camada extra de segurana no acesso a arquivos importantes, j que alm do login e senha, verificado a partir de qual mquina o acesso proveniente.

Isso feito atravs das opes "hosts allow" e "hosts deny" que permitem, respectivamente, criar uma lista de mquinas que podem e que no podem acessar o compartilhamento. As listas podem incluir tanto os endereos IP quanto os nomes das mquinas.

Para restringir o acesso ao compartilhamento a apenas duas mquinas especficas, voc usaria:

[arquivos]


writable = yes

hosts allow = 192.168.1.23, 192.168.1.24ou

[arquivos]


writable = yes

hosts allow = sparta, athenas possvel tambm fazer o inverso, bloqueando o compartilhamento para acessos provenientes das duas mquinas. Nesse caso, mesmo que o usurio tente acessar usando um login vlido, vai receber a mensagem de acesso negado, como se o login tivesse sido bloqueado ou a senha tenha sido alterada. A lista no possui um tamanho mximo, voc pode incluir quantas mquinas precisar, separando os endereos ou nomes por vrgula e espao. Voc pode inclusive misturar endereos IP com nomes de mquinas, como nesse exemplo:

[arquivos]


writable = yes

hosts deny = 192.168.1.23, athenas possvel ainda combinar a restrio com base nos nomes e endereos com a restrio com base nos logins de acesso, de forma que o acesso seja autorizado apenas quando as duas condies forem satisfeitas.

Para permitir que apenas a maria e o joao acessem o compartilhamento e ainda assim apenas se estiverem usando uma das duas mquinas permitidas, voc usaria:

[arquivos]

path = /home/arquivos

writable = yes

valid users = maria, joaohosts allow = 192.168.1.23, 192.168.1.24Voc pode autorizar ou restringir o acesso para uma faixa inteira de endereos omitindo o ltimo octeto do endereo. Por exemplo, para que apenas clientes dentro da rede "192.168.1.x" tenham acesso, voc inclui apenas a parte do endereo referente rede, omitindo o octeto referente ao host, como em:

[arquivos]


writable = yes

hosts allow = 192.168.1.Se precisar criar excees, limitando o acesso a algumas mquinas dentro da faixa de endereos especificada, voc pode usar a opo "EXCEPT" para especificar as excees, como em:

[arquivos]


writable = yes

hosts allow = 192.168.1. EXCEPT 192.168.1.23, 192.168.1.24Com isso, todos os endereos dentro da faixa teriam acesso, com exceo do .23 e do .24. O mesmo pode ser feito ao usar a opo "hosts deny", como em:

[restrito]

path = /mnt/sda2/restrito

writable = yes

valid users = isac

hosts deny = 192.168.1. EXCEPT 192.168.1.23Aqui a lgica invertida e todos os hosts dentro da faixa de endereos so bloqueados, com exceo do .23, que passa a ser o nico aceito pelo servidor.

Outro parmetro que pode ser usado ao criar excees o "ALL", que inclui todos os endereos possveis. Se a idia que apenas um determinado endereo possa acessar o compartilhamento, uma opo usar "hosts deny = ALL EXCEPT 192.168.1.34".

O default do Samba permitir o acesso a partir de qualquer mquina, de forma que se voc no usar nem a opo "hosts allow", nem a "hosts deny", qualquer mquina poder acessar o compartilhamento.

Ao usar apenas a opo "hosts allow", apenas as mquinas listadas tero acesso ao compartilhamento, as demais sero recusadas. Ao usar apenas a opo "hosts deny", apenas as mquinas listadas no tero acesso ao compartilhamento (as demais continuam acessando).

Ao combinar o uso das opes "hosts allow" e "hosts deny", a opo "hosts allow" tem precedncia (no importa a ordem em que elas sejam colocadas), de forma que as mquinas listadas tero acesso, mesmo que ele seja negado pela opo "hosts deny". Por exemplo, ao usar:

[isos]

path = /mnt/isos

hosts allow = 192.168.1.

hosts deny = 192.168.1.43

comment = Algo est errado

... o host "192.168.1.43" continuar tendo acesso ao compartilhamento, pois faz parte da faixa de endereos cujo acesso autorizado pela opo "hosts allow". Neste caso, o Samba no considera a opo "hosts deny = 192.168.1.43" como uma exceo, mas sim como um erro de configurao. Para bloquear a mquina, voc deveria usar:

[isos]

path = /mnt/isos

hosts allow = 192.168.1. EXCEPT 192.168.1.43

comment = Agora sim

Em situaes onde voc precisa restringir temporariamente o acesso a um determinado compartilhamento (para alguma tarefa de manuteno, por exemplo) voc pode usar a opo "available = no", como em:

[arquivos]


writable = yes

valid users = maria, joao

available = noEla faz com que o compartilhamento "desaparea", da mesma forma que se voc apagasse ou comentasse a configurao. A principal vantagem que ao apagar voc precisaria escrever tudo de novo para reativar o compartilhamento, enquanto ao usar o "available = no" voc precisa apenas remover a opo ou mudar para "available = yes".

Outra opo interessante que pode ser includa a "browseable = no", que transforma o compartilhamento em um compartilhamento oculto:

[arquivos]


writable = yes

browseable = noCom isso, ele no aparece mais no ambiente de redes, mas pode ser acessado normalmente se voc especificar o nome manualmente ao mapear o compartilhamento:

Essa no propriamente uma opo de segurana, mas pode ser usada para afastar os curiosos dos compartilhamentos com acesso restrito.

Concluindo, muitas opes que ficam disponveis no Swat podem ser omitidas ao configurar manualmente, simplesmente porque so o default no Samba. O prprio Swat evita incluir opes redundantes ao gerar o arquivo, incluindo apenas as configuraes que so diferentes dos valores default.

No necessrio incluir opes como "writable =no", "available = yes" ou "browseable = yes" no arquivo, pois estes j so os valores usados por padro no Samba. Apesar disso, us-los tambm no atrapalha em nada, de forma que nada impede que voc os inclua no arquivo para se lembrar mais facilmente das opes.

Outra dica que voc pode verificar a qualquer momento quais usurios e quais mquinas esto acessando compartilhamentos no servidor usando o comando "smbstatus, como em:"

# smbstatus

Samba version 3.0.24

PID Username Group Machine

-------------------------------------------------------------------

17107 gdh gdh hp (192.168.1.2)

11588 gdh gdh semprao (192.168.1.10)

Service pid machine Connected at

-------------------------------------------------------

IPC$ 17107 hp Sun Oct 28 15:54:04 2007

arquivos 11588 semprao Sun Oct 28 15:23:59 2007

No locked files

Neste exemplo, podemos ver que o usurio "gdh" est logado no servidor a partir de duas mquinas diferentes, um indcio de que duas pessoas esto utilizando a mesma conta.

A seo [global]


Carlos E. Morimoto24/06/2009Todas as opes colocadas dentro da seo referente ao compartilhamento valem apenas para ele, o que permite que voc crie diversos compartilhamentos diferentes e use um conjunto prprio de permisses para cada um. Estas mesmas opes, junto com um conjunto adicional podem ser especificadas de forma geral dentro da seo [global] do smb.conf.

Nos exemplos anteriores, especificamos apenas o nome do servidor e o grupo de trabalho na seo [global]. Isto suficiente para o servidor participar da rede e compartilhar arquivos, mas, naturalmente, existem muitas outras opes que podem ser usadas.

Em primeiro lugar, temos o nvel de segurana do servidor, definido atravs da opo "security". O default no Samba 3 usar o controle de acesso baseado em usurio, que o mesmo modo de acesso usado pelas verses domsticas do Windows 2000, XP e Vista. Neste modo, voc cadastra os logins e senhas no servidor, define as permisses de acesso e o servidor checa as credenciais dos clientes antes de autorizar o acesso, a configurao que vimos at aqui. Este modo ativado adicionando a opo "security = user" na seo [global], mas no necessrio us-la no Samba 3, pois, como disse, ela usada por padro:

security = user

Em seguida, temos o modo "security = domain". Ao contrrio do que o nome pode sugerir primeira vista, este modo no destinado a fazer com que o Samba atue como um controlador de domnio. Pelo contrrio, ao configurar um servidor Samba como PDC, voc continua usando a opo "security = user", da mesma forma que faria ao usar um servidor em modo stand alone. A opo "security = domain" usada quando voc quer que um servidor Samba participe do domnio como cliente, autenticando-se em um servidor PDC j existente (que pode tanto ser outro servidor Samba, quanto ser um servidor Windows).

Existem ainda os modos "security = share" e "security = server", que imitam o sistema de acesso utilizado por estaes Windows 95/98. Estes dois modos so obsoletos e devem ser removidos em futuras verses do Samba. Antigamente, o modo "security = share" era usado em casos onde voc queria disponibilizar compartilhamentos pblicos na rede, sem muita segurana, mas hoje em dia isso pode ser feito usando a conta guest (como veremos em detalhes mais adiante). O modo "security = server" descende da poca em que o Samba ainda no era capaz de atuar como PDC; este modo permitia que ele atuasse como um proxy de autenticao, repassando as requisies para o servidor de autenticao principal. Atualmente este modo no mais usado.

Outra opo usada por padro no Samba 3 a "encrypt passwords = yes", de forma que tambm no necessrio especific-la manualmente no arquivo. Entretanto, saudvel inclu-la em modelos e exemplos de configurao pois pode acontecer de algum tentar usar o modelo no Samba 2, onde o default era que ela ficasse desativada.

encrypt passwords = yes

muito comum que seja includa tambm a opo "invalid users = root", uma medida de segurana para evitar que a conta de root seja usada ao acessar o servidor. A lgica que a conta de root a nica conta presente em qualquer sistema Linux, de forma que algum que decidisse usar um ataque de fora bruta para tentar obter acesso ao servidor, testando todas as senhas possveis, comearia justamente pela conta de root.

Entretanto, a conta de root necessria para dar upload de drivers de impresso e para logar os clientes ao usar o servidor Samba como PDC, situaes onde a linha "invalid users = root" deve ser comentada ou removida.

Continuando, as opes definidas dentro da seo [global] valem para todos os compartilhamentos do servidor, diferente das opes colocadas dentro da seo referente a cada um. Por exemplo, ao usar:

[global]

netbios name = Servidor

workgroup = Grupo

hosts allow = 192.168.1.

... apenas as mquinas dentro da faixa de endereos especificadas tero acesso ao servidor, o que seria interessante do ponto de vista da segurana, j que de qualquer forma o servidor deve ser acessado apenas por clientes da rede local.

O maior problema que a opo "hosts allow" usada na seo [global] tem precedncia sobre qualquer opo "hosts deny" usada dentro dos compartilhamentos, o que pode criar problemas caso voc queira restringir o acesso de alguma mquina da rede local a um determinado compartilhamento.

Por exemplo, ao usar:

[global]


workgroup = Grupo

hosts allow = 192.168.1.[share]

path = /mnt/sda2/shared

hosts deny = 192.168.1.2... a mquina "192.168.1.2" continuaria tendo acesso ao compartilhamento [share], pois o acesso autorizado pela opo "hosts allow = 192.168.1." usada na seo [global]. Nesse caso, o melhor seria remover a linha "hosts allow = 192.168.1." da seo [global] e deixar apenas a opo "hosts deny = 192.168.1.2" na seo [share]:

[global]


workgroup = Grupo

[share]


hosts deny = 192.168.1.2Em caso de conflito direto entre uma regra definida na seo [global] e outra definida em um dos compartilhamentos, a regra definida na seo [global] tem precedncia. Por exemplo, ao usar:

[global]


workgroup = Grupo

hosts deny = 192.168.1.3[share]


hosts allow = 192.168.1.3... a mquina "192.168.1.3" continuar sem acesso ao compartilhamento "share" (ou a qualquer outro recurso do servidor), j que vale a regra definida na seo [global]. Enquanto a linha "hosts deny = 192.168.1.3" no for removida, a mquina no ter acesso a nenhum dos compartilhamentos, no importa o que digam as demais linhas do arquivo.

Continuando, um problema comum enfrentado ao administrar uma rede mista so os usurios escreverem a primeira letra do login em maisculo, como em "Joao" no lugar de "joao". No Windows isso no um problema, j que o sistema case insensitive, mas no Linux faz com que o sistema recuse o login. Uma forma de evitar isso no Samba usar a opo "username level", como em:

username level = 2

Esta opo faz com que o Samba verifique vrias combinaes de maisculas e minsculas caso o login seja recusado pelo sistema. O nmero indica o volume de variaes, que pode ser qualquer nmero inteiro. Ao usar o valor "2", o Samba verifica at dois nveis, incluindo variaes como JOao, jOAo, Joao, jOaO e assim por diante. Usar um nmero maior pode retardar a autenticao, j que o Samba precisar testar muitas combinaes, por isso so geralmente usados os valores "1" ou "2".

Outra peculiaridade digna de nota a questo dos nomes de arquivos. No Windows, os nomes de arquivos so salvos da forma como digitados pelo usurio, preservando os caracteres maisculos e minsculos. Entretanto, o sistema case insensitive, de forma que o sistema no diferencia um arquivo chamado "Trabalho.txt" de outro chamado "trabalho.txt".

Embora o Linux seja case sensitive, o Samba tenta emular o comportamento de uma mquina Windows ao localizar arquivos. Se o cliente pede o arquivo "Trabalho.txt", quando na verdade o arquivo armazenado na pasta se chama "trabaLho.txt" o Samba vai acabar fornecendo o arquivo correto para o cliente, pois o encontrar depois de testar diversas combinaes de maisculas e minsculas.

No Samba 3 este recurso funciona muito bem, mas tem a desvantagem de consumir uma certa quantidade de memria do servidor. Em um pequeno servidor de rede local, isso no faz diferena, mas em um servidor que atende um grande nmero de requisies, a diferena pode se tornar considervel.

Voc pode simplificar as coisas orientando o Samba a salvar todos os arquivos em minsculas. Para isso, adicione as linhas:

preserve case = no

default case = lower

No caso de servidores com duas ou mais interfaces de rede, sobretudo no caso de servidores conectados simultaneamente internet e rede local, voc pode especificar qual interface ser usada pelo Samba atravs da opo "interfaces", que deve ser combinada com a opo "bind interfaces only = yes". Para que o servidor escute apenas a interface eth0, ignorando tentativas de conexo em outras interfaces, voc usaria:

interfaces = eth0

bind interfaces only = yes

Por default, o Samba escuta em todas as interfaces, o que (se no houver nenhum firewall ativo) pode expor seus compartilhamentos para a Internet caso voc ative o Samba em uma mquina conectada diretamente internet, como no caso de um servidor que compartilha a conexo. recomendvel usar sempre estas duas opes, como uma forma de garantir que o Samba ficar disponvel apenas na interface desejada.

Outra opo interessante a "netbios aliases", que permite criar "apelidos" para o servidor, de modo de que ele possa ser acessado por mais de um nome. Usando um alias, o servidor realmente aparece duas ou mais vezes no ambiente de rede, como se existissem vrias mquinas. Geralmente, isso acaba confundindo mais do que ajudando, mas pode ser til em algumas situaes, quando, por exemplo, um servidor desativado e os compartilhamentos so movidos para outro. O novo servidor pode responder pelo nome do servidor antigo, permitindo que os desavisados continuem acessando os compartilhamentos atravs do endereo anterior. Para us-la, basta adicionar a opo, seguida pelos apelidos desejados, como em:

[global]


netbios aliases = athenas, sparta

workgroup = Grupo

No tpico sobre o Swat falei sobre as opes "Local Master", "OS Level" e "Preferred Master", que definem se o servidor Samba deve participar das eleies para Master Browser e com qual nvel de credencial. Para que o servidor participe com OS Level 100, voc adicionaria as linhas:

local master = yes

os level = 100

preferred master = yes

Um segundo servidor Samba na rede poderia participar com uma credencial mais baixa, de forma a assumir o cargo apenas caso o servidor principal esteja desconectado da rede. Para isso, basta usar um valor mais baixo na opo OS Level, como em:

local master = yes

os level = 90

preferred master = no

O valor da opo OS Level absoluto, no se trata de um sorteio. Um servidor configurado com o valor "100" ganha sempre de um com o valor "99", por exemplo.

Se voc omitir as trs linhas, o servidor simplesmente utiliza os valores default (local master = yes, os level = 20), que fazem com que ele participe das eleies, mas utilize credenciais baixas.

A opo "wins support = yes" faz com que o servidor Samba passe a trabalhar como um servidor WINS (Windows Internetworking Name Server) na rede. O WINS um protocolo auxiliar dentro das redes Microsoft, responsvel pela navegao na rede e listagem dos compartilhamentos e outros recursos disponveis, de forma similar a um servidor DNS.

O uso do WINS no obrigatrio; sua rede vai muito provavelmente funcionar muito bem sem ele. Entretanto, sem um servidor WINS os clientes passam a usar pacotes de broadcast para a navegao (a menos que voc utilize um domnio), o que aumenta o trfego da rede e torna todo o processo mais passvel de falhas.

Outra limitao importante que os pacotes de broadcast so descartados pelos roteadores, o que faz com que eles (os pacotes de broadcast) no sejam transmitidos de um segmento a outro da rede caso ela esteja dividida em vrios segmentos, interligados atravs de roteadores. O mesmo acontece caso voc tenha duas redes ligadas atravs de uma VPN, onde o trfego seja roteado. Em ambos os casos, os pacotes de broadcast so descartados pelos roteadores, fazendo com que os micros em um segmento no enxerguem os micros do outro e vice-versa.

A soluo em ambos os casos implantar um servidor WINS na rede. Com isso, os clientes passam a consultar o servidor ao invs de mandar pacotes de broadcast, fazendo com que a navegao funcione mesmo ao utilizar vrios segmentos de rede. Para isso, basta incluir a opo dentro da seo [global] do smb.conf:

wins support = yes

O prximo passo configurar os clientes da rede para utilizarem o servidor. A opo fica escondida nas propriedades da conexo de rede, no Protocolo TCP/IP > Propriedades > Avanado > WINS, onde voc deve adicionar o endereo IP do servidor:

A configurao do servidor WINS pode ser tambm enviada automaticamente para os clientes. Para isso, necessrio incluir a opo "netbios-name-servers" na configurao do servidor DHCP (no arquivo "/etc/dhcp3/dhcpd.conf", ou "/etc/dhcpd.conf"), especificando o nome do servidor, como em:

option netbios-name-servers 192.168.1.254;

Esta linha colocada dentro da seo com a configurao da rede, como nesse exemplo:

subnet 192.168.1.0 netmask 255.255.255.0 {

range 192.168.1.100 192.168.1.199;

option routers 192.168.1.1;

option domain-name-servers 192.168.1.1;

option netbios-name-servers 192.168.1.254;option broadcast-address 192.168.1.255;

}

No caso de outros micros Linux rodando o Samba que forem ser configurados como clientes do servidor principal, a configurao feita adicionando a opo "wins server = servidor" (tambm na seo [global] do smb.conf), onde voc especifica o endereo IP do servidor principal, como em:

wins server = 192.168.1.254

Uma observao importante que as opes "wins support" e "wins server" so mutuamente exclusivas. Ou a mquina atua como servidor WINS, ou como cliente (nunca as duas coisas ao mesmo tempo), de forma que voc no deve jamais combinar as duas opes dentro da configurao.

Em verses antigas do Samba, combinar as duas opes na configurao simplesmente fazia com que o servidor deixasse de funcionar. Nas atuais o resultado no chega a ser dramtico (o servidor vai simplesmente ignorar a opo que for colocada depois), mas mesmo assim este um erro grave de configurao que deve ser evitado.

Um exemplo de seo [global] usando as opes que vimos at aqui seria:

[global]

netbios name = Athenas

server string = Servidor Samba

workgroup = Grupo

username level = 1

preserve case = no

default case = lower

interfaces = eth0

bind interfaces only = yes

local master = yes

os level = 100


wins support = yes

Esta configurao ativa o teste de variaes de maisculas e minsculas para os logins recusados (apenas um nvel), faz com que todos os arquivos salvos nos compartilhamentos sejam renomeados para caracteres minsculos, faz com que o servidor escute apenas a interface eth0, que seja master browser da rede e que atue como servidor WINS. Este um arquivo de configurao perfeitamente utilizvel, faltaria apenas adicionar as sees referentes aos compartilhamentos.

A seo [homes]


Carlos E. Morimoto24/06/2009Uma vantagem de utilizar usurios "reais" no servidor Samba, em vez de usurios castrados, que voc tem a opo de compartilhar os diretrios home atravs da seo [homes] no smb.conf. Este um servio interno do Samba, que permite compartilhar automaticamente o diretrio home de cada usurio, sem precisar criar um compartilhamento separado para cada um.

A configurao mais comum compartilhar os diretrios home com permisso de acesso apenas para o respectivo usurio. Dessa forma, cada usurio tem acesso apenas ao seu prprio diretrio home (que aparece no ambiente de redes como um compartilhamento com o mesmo nome), sem poder acessar, nem muito menos alterar o contedo dos diretrios home dos demais usurios. Nesse caso, a configurao fica:

[homes]

valid users = %S

read only = no

create mask = 0700

directory mask = 0700

browseable = no

No necessrio especificar a pasta a compartilhar, pois ao omitir a linha "path" o Samba sabe que deve compartilhar o home de cada usurio. As opes "create mask = 0700" e "directory mask = 0700" fazem com que todos os arquivos e pastas criados pelo usurio dentro do home sejam acessveis apenas por ele mesmo. A opo "browseable = no" faz com que cada usurio possa ver apenas seu prprio diretrio, o que reforado pela opo "valid users = %S", que diz explicitamente que apenas o prprio usurio deve ter acesso sua pasta home.

Uma queixa comum que ao acessar o diretrio home atravs do Samba, os usurios vero todos os arquivos e pastas de configurao de programas que so salvos dentro do diretrio home, o que pode ser confuso.

Uma forma de evitar isso alterar a configurao, de forma que o Samba compartilhe uma pasta vazia dentro do home, e no o diretrio home em si. Com isso mantido o propsito de oferecer uma pasta particular para o usurio, onde ele possa salvar seus arquivos particulares e seus backups, sem a poluio gerada pela presena dos arquivos de configurao. A configurao nesse caso ficaria:

[homes]

path = /home/%u/share

valid users = %S

read only = no

create mask = 0700

directory mask = 0700

browseable = no

A linha "path = /home/%u/share" especifica que o Samba deve agora compartilhar a pasta "share" dentro do home e no mais o diretrio home em si (voc pode especificar outra pasta qualquer) e a linha "valid users = %S" garante que a pasta ficar acessvel apenas para o prprio usurio.

Naturalmente, a pasta "share" precisa ser criada dentro do home de cada usurio manualmente. Voc pode fazer isso de forma automtica para todos os usurios usando este mini shell script:

cd /home

for i in *; do

mkdir $i/share

chown $i:$i $i/share

done

Aproveite para criar tambm a pasta "share" dentro do diretrio "/etc/skel", que usado como um modelo para a criao do home de novos usurios. Isso faz com que o diretrio seja adicionado ao home de todos os usurios criados da em diante, de forma automtica:

# mkdir /etc/skel/share

Concluindo, aqui vai uma lista de outras variveis do Samba para referncia:

%a : A verso do Windows usada, onde o "%a" substitudo pelas strings "Win95" (Windows 95/98), "WinNT" (Windows NT 3.x ou 4.x), "Win2K" (Windows 2000 ou XP) ou "Samba" (mquinas Linux rodando o Samba)

%I : Endereo IP da mquina cliente (ex: 192.168.1.2)

%m : Nome da mquina cliente (ex: cliente1)

%L : Nome do servidor (ex: athenas)

%u : Nome do usurio, como cadastrado no servidor Linux (ex: joao)

%U : Nome do usurio, como enviado pelo cliente Windows (pode ser diferente do login cadastrado no servidor em algumas situaes)

%H : Diretrio home do usurio (ex: /home/maria)

%g : Grupo primrio do usurio (ex: users)

%S : Nome do compartilhamento atual (o valor informado entre colchetes, ex: arquivos)

%P : Pasta compartilhada (o valor informado na opo "path", ex: /mnt/arquivos)

%v : Verso do Samba (ex: 3.2.24)

%T : Data e horrio atual

Ao longo do texto, veremos alguns outros exemplos de uso destas variveis, mas voc pode us-las em outras situaes para criar compartilhamentos "inteligentes", que mostram pastas diferentes de acordo com as propriedades do cliente. Por exemplo, a varivel "%a" (que indica a verso do Windows no cliente), poderia ser usada para criar um compartilhamento com drivers, que mostrasse diretamente a pasta com os drivers corretos para a verso do Windows usada. Nesse caso, voc poderia usar algo como:

[drivers]

path = /mnt/sda2/drivers/%a

read only = yes

A pasta "/mnt/sda2/drivers/" incluiria uma srie de sub-pastas, com os valores possveis para a varivel, incluindo "Win95", "WinNT", "Win2K" e "Samba". Ao acessar o compartilhamento, o cliente v apenas o contedo da pasta correspondente ao sistema operacional usado.

A conta guest


Carlos E. Morimoto24/06/2009No Windows XP usado por padro um modo simplificado de compartilhamento de arquivos, o "simple sharing", que visa imitar o modo de acesso do Windows 95/98, onde os compartilhamentos so pblicos e voc apenas define se eles so apenas leitura ou leitura e escrita.

Na verdade, o Windows XP usa o controle de acesso com base no usurio, assim como o Samba 3, mas, por baixo dos panos, todos os acessos passam a ser mapeados para a conta "guest" (ativa por padro), o que permite que usurios remotos sem login vlido acessem os compartilhamentos diretamente. Este recurso tambm chamado de "force guest".

Naturalmente, podemos fazer o mesmo no Samba. Para isso, adicione as linhas abaixo dentro da seo [global] do smb.conf:

map to guest = bad userguest account = guestA primeira opo faz com que sempre que um cliente especificar um usurio invlido ao tentar acessar o servidor, o servidor mapeie a requisio para o login especificado na opo "guest account", que usada para acessar o compartilhamento. Neste exemplo, qualquer usurio no autenticado passaria a usar a conta "guest", que deve ter sido previamente cadastrada no servidor. Voc pode tambm usar qualquer outra conta vlida, como em "guest account = maria".

Uma opo menos usada a "map to guest = bad password". Ela se diferencia da "map to guest = bad user" pois permite o acesso apenas caso o usurio especifique um login vlido, mas erre apenas a senha. O principal motivo dela no ser muito usada que ela confunde o usurio, j que ele ou vai achar que est realmente logado no servidor (quando na verdade est apenas acessando de forma limitada atravs da conta guest) ou vai passar a achar que o servidor aceita qualquer senha.

Para que os usurios no-autenticados possam acessar os compartilhamentos, voc deve explicitamente autorizar o acesso, adicionando a opo "guest ok = yes" na configurao, como em:

[global]


workgroup = Grupo

map to guest = bad user

guest account = guest

[publico]

path = /mnt/sda2/publico

writable = yes

guest ok = yesNote que no exemplo usei a opo "writable = yes". Entretanto, para que os usurios no-autenticados possam efetivamente escrever na pasta, necessrio verificar se as permisses de acesso da pasta permitem que a conta especificada ("guest" no exemplo) altere os arquivos. Como disse anteriormente, o Samba est subordinado s permisses de acesso do sistema.

Outra opo comum em compartilhamentos pblicos a "guest only = yes" (usada no lugar da "guest ok = yes", na seo [global]). Ela simula o "simple sharing" do Windows XP, mapeando qualquer acesso para a conta guest, sem sequer abrir o prompt de login para o cliente.

Vamos ento a mais um exemplo de configurao do smb.conf, desta vez usando a conta guest para criar um servidor de arquivos pblico. Ele possui duas parties de arquivos (montadas nas pastas "/mnt/hda2 e "/mnt/sda1") que ficam disponveis a todos os usurios da rede:

[global]

netbios name = Plutus

server string = Servidor pblico

workgroup = Grupo

local master = yes

os level = 100


wins support = yes

map to guest = bad userguest account = gdh[arquivos]

path = /mnt/hda2

writable = yes

guest ok = yes[backups]

path = /mnt/sda1

writable = yes

guest ok = yesEsta configurao bastante simples e a prova de falhas. O servidor vai assumir a funo de master browser, se responsabilizando pela navegao dos clientes e vai mapear qualquer acesso para a conta "gdh" usada na opo "guest account", permitindo que qualquer um possa ler e gravar arquivos nos dois compartilhamentos.

As duas principais observaes so que o usurio "gdh" deve ser um usurio real do sistema, cadastrado no servidor Samba, e que ele deve ser o dono das duas pastas compartilhadas, de forma que no tenha problemas para acessar seu contedo. Isso pode ser feito usando os 4 comandos a seguir:

# adduser gdh

# smbpasswd -a gdh

# chown -R gdh:gdh /mnt/hda2# chown -R gdh:gdh /mnt/sda1Essa configurao ideal para pequenos servidores de rede local, que devem apenas disponibilizar arquivos na rede, sem muita segurana. Ela similar ao exemplo de configurao para um servidor de arquivos pblico que inclu no livro Redes, Guia Prtico.

Lixeira no Samba


Carlos E. Morimoto24/06/2009Em qualquer servidor de arquivos, a principal prioridade assegurar a integridade e a segurana dos dados. Entretanto, por mais estvel que seja a rede e por mais robusto que seja o servidor, o elo mais fraco da cadeia acaba sendo sempre o usurio. De nada adianta um servidor perfeitamente estvel se ele deleta um arquivo importante sem querer.

Pensando nisso, o Samba oferece a opo de usar uma lixeira, que pode lhe poupar muita dor de cabea em diversas situaes. Isso feito atravs da opo "vfs object = recycle", que cria uma lixeira dentro de cada pasta compartilhada, que passa a armazenar todos os arquivos deletados. Isso previne a remoo acidental de arquivos, j que o usurio passa a precisar deletar o arquivo e em seguida limpar o contedo da lixeira para realmente remov-lo, o que o comportamento esperado por muitos.

Por padro, os arquivos deletados vo para a pasta ".recycle" (dentro do compartilhamento), mas o nome pode ser alterado atravs da opo "recycle:repository = lixeira" (onde o "lixeira" o nome desejado, que pode ser qualquer um). Quando uma pasta deletada, o padro simplesmente misturar todos os arquivos no diretrio raiz da lixeira, mas isso pode ser evitado adicionando a opo "recycle:keeptree = yes". Aqui temos mais um exemplo de compartilhamento, incluindo as trs opes:

[projetos]

path = /mnt/sda2/projetos

writable = yes

valid users = +apolo, isac

vfs object = recyclerecycle:repository = lixeirarecycle:keeptree = yesOutra opo til a "recycle:versions", que faz com que a lixeira mantenha diferentes verses do mesmo arquivo, em vez de manter apenas a ltima verso. Os arquivos repetidos passam ento a ser renomeados para "Copy #1 of Samba.sxw", "Copy #2 of Samba.sxw" e assim por diante.

recycle:versions = yes

Com isso, voc passa a dormir um pouco mais tranquilo a noite e se salva (na maior parte dos casos) de precisar recuperar arquivos acidentalmente deletados a partir de backups. preciso apenas se lembrar de verificar o contedo das lixeiras de vez em quando e limpar as pastas quando elas comearem a consumir muito espao em disco. Voc pode inclusive deletar a pasta da lixeira inteira, pois ela recriada automaticamente quando o prximo arquivo for deletado.

Uma opo para reduzir o problema do espao desperdiado centralizar todas as lixeiras em uma nica pasta. Isso permite inclusive que voc utilize uma partio ou um HD separado para armazenar os arquivos da lixeira, sem correr o risco de ela crescer at ocupar todo o espao disponvel na partio principal. Para isso, usamos a opo "recycle:repository", seguida da pasta a ser utilizada (que deve ser criada previamente), como em:

recycle:repository = /var/samba/trash/

Como adicionamos o caminho completo (em vez de usar "recycle:repository = lixeira", como no exemplo anterior), a opo pode tanto ser adicionada individualmente em cada compartilhamento quanto ser especificada apenas uma vez na seo [global], o que faz com que a lixeira passe a ser automaticamente usada para arquivos deletados em todos os compartilhamentos do servidor.

Centralizar todos os arquivos em uma nica pasta criaria uma grande confuso, j que ela misturaria arquivos deletados por todos os usurios. Uma soluo adicionar a varivel "%U", que faz com que os arquivos sejam organizados em vrias subpastas, separados por usurio (as subpastas usadas por cada usurio so criadas automaticamente conforme necessrio). Nesse caso a opo fica:

recycle:repository = /var/samba/trash/%U

O problema em usar essa opo que os usurios deixam de ver a lixeira, j que ela passa a ficar em uma pasta separada. Uma soluo para o problema criar um novo compartilhamento, que permite que cada usurio veja sua lixeira particular. Para isso, iremos novamente usar a varivel "%U":

[lixeira]

path = /var/samba/trash/%U

writable = yes

Usei a opo "writable = yes" para permitir que o prprio usurio possa limpar a lixeira quando quiser, mas isso opcional. Vale lembrar que para que o usurio consiga limpar os arquivos da lixeira, necessrio que ele tenha permisso de escrita para a pasta "/var/samba/trash/". Nesse caso, voc tem a opo de simplesmente abrir as permisses da pasta (chmod 777), ou ajustar manualmente as permisses da sub-pasta de cada usurio, como em:

# chown -R joao:joao /var/samba/trash/joao

Mais uma medida til para evitar desperdcio de espao bloquear a gravao de arquivos de backup e de arquivos temporrios na lixeira, j que eles costumam ser numerosos e raramente so importantes. saudvel bloquear tambm arquivos .iso (que so tipicamente muito grandes), de forma que eles sejam tambm deletados diretamente. As extenses de arquivos so especificadas atravs da opo "recycle:exclude" e nomes de pasta atravs da opo "recycle:exclude_dir", como em:

recycle:exclude = *.tmp, *.log, *.obj, ~*.*, *.bak, *.iso

recycle:exclude_dir = tmp, cache

Assim como a "recycle:repository", as demais opes da lixeira podem tanto serem especificadas individualmente dentro de cada compartilhamento quanto diretamente dentro da seo [global], o que naturalmente o mais simples caso voc deseje ativ-la para todos os compartilhamentos. O default do Samba 3 manter todas as opes desativadas, de forma que a lixeira s usada quando as opes so especificadas.

Um exemplo de configurao, com a lixeira ativa dentro da seo [global], dois compartilhamentos de arquivos e mais o compartilhamento que d acesso pasta central da lixeira por parte dos usurios seria:

[global]

netbios name = Phanteon

server string = Servidor com lixeira

workgroup = Grupo

local master = yes

os level = 100


wins support = yes

vfs objects = recyclerecycle:keeptree = yesrecycle:versions = yesrecycle:repository = /var/samba/trash/%Urecycle:exclude = *.tmp, *.log, *.obj, ~*.*, *.bak, *.isorecycle:exclude_dir = tmp, cache[engenharia]

path = /mnt/sda2/engenharia

writable = yes

valid users = +engenheiros

[gerencia]

path = /mnt/gerencia

writable = yes

valid users = paulo, rebeca

hosts allow = micro3, micro4

browseable = no

[lixeira]path = /var/samba/trash/%Uwritable = yes

Pgina 06 de 08

Auditando os acessos


Carlos E. Morimoto24/06/2009O Samba oferece tambm um recurso de gerao de log. Ele pode ser ativado adicionando as opes abaixo na seo [global] do smb.conf:

log level = 1

log file = /var/log/samba.log

max log size = 1000

A opo "log level" indica o nvel das mensagens (de 0 a 10), sendo que o nvel 0 mostra apenas mensagens crticas, o nvel 1 mostra alguns detalhes sobre os acessos e os demais mostram diversos nveis de informaes de debug, teis a desenvolvedores. A opo "log file" indica o arquivo onde ele ser gerado e a "max log size" indica o tamanho mximo, em kbytes.

A partir do Samba 3.04 foi includo um mdulo de auditoria, que permite logar os acessos e as modificaes feitas de uma forma muito mais completa que o log tradicional. Isso feito atravs do mdulo "full_audit", que (do ponto de vista tcnico) funciona de forma similar ao mdulo "recycle" usado pela lixeira.

O primeiro passo ativar o mdulo, o que feito atravs da linha abaixo:

vfs objects = full_audit

O prximo passo definir quais operaes devem ser logadas atravs da opo "full_audit:success", como em:

full_audit:success = open, opendir, write, unlink, rename, mkdir, rmdir, chmod, chown

(as opes formam uma nica linha)

As opes que inclu no exemplo so open (ler um arquivo), opendir (ver os arquivos dentro de uma pasta), write (alterar um arquivo), unlink (deletar um arquivo), rename (renomear um arquivo), mkdir (criar um diretrio), rmdir (remover um diretrio), chmod (alterar as permisses de acesso de um arquivo) e chown (mudar o dono de um arquivo).

Voc pode remover algumas destas opes, deixando apenas as opes desejadas, ou ver uma lista completa das opes que podem ser includas no manual do vfs_full_audit, disponvel no:

http://samba.org/samba/docs/man/manpages-3/vfs_full_audit.8.htmlContinuando a configurao, especificamos as informaes que desejamos que sejam includas no log, usando a opo "full_audit:prefix". Aqui podemos utilizar as variveis que mostrei no tpico sobre o compartilhamento [homes], como a "%u" (o nome do usurio), "%I" (o IP da mquina) e "%S" (o nome do compartilhamento onde foi feito o acesso ou a alterao). No necessrio incluir a varivel referente ao nome da mquina, pois o nome includo automaticamente:

full_audit:prefix = %u|%I|%S

Por padro, o mdulo loga no apenas os acessos e modificaes, mas tambm um grande volume de mensagens de alerta e erros gerados durante a operao. A opo "full_audit:failure = none" evita que estas mensagens sejam logadas, fazendo com que o log fique muito mais limpo e seja mais fcil encontrar as opes que realmente interessam:

full_audit:failure = none

Concluindo, especificamos o nvel dos alertas, entre os suportados pelo syslog, como em:

full_audit:facility = local5

full_audit:priority = notice

Juntando tudo, temos:

vfs objects = full_audit

full_audit:success = open, opendir, write, unlink, rename, mkdir, rmdir, chmod, chown

full_audit:prefix = %u|%I|%S

full_audit:failure = none

full_audit:facility = local5

full_audit:priority = notice

Esta configurao pode ser tanto includa dentro da seo [global] (de forma que o log inclua os acessos e as alteraes feitas em todos os compartilhamentos) quanto ser includa apenas na configurao de um compartilhamento especfico.

Com isso, o Samba vai passar a gerar os eventos referentes aos acessos. Falta agora configurar o sysklogd (o servio responsvel pela gerao dos logs do sistema), para logar os eventos, gerando o arquivo de log que poder ser consultado. Para isso, abra o arquivo "/etc/syslog.conf" e adicione a linha abaixo:

local5.notice /var/log/samba-full_audit.logNote que o "local5.notice" corresponde aos valores informados nas opes "full_audit:facility" e "full_audit:priority", enquanto o "/var/log/samba-full_audit.log" o arquivo de log que ser gerado.

Depois de concluda a configurao, reinicie os servios e o log passar a ser gerado imediatamente:

# /etc/init.d/samba restart

# /etc/init.d/sysklogd restart

Dentro do arquivo, voc ver entradas contendo a data e hora, o nome da mquina, o usurio, o IP da mquina, o nome do compartilhamento, a operao realizada e o nome do arquivo ou pasta onde ela foi realizada, como em:

Nov 18 15:21:15 m5 smbd_audit: joao|192.168.1.23|arquivos|opendir|ok|. Nov 18 15:21:29 m5 smbd_audit: joao|192.168.1.23|arquivos|open|ok|r|addr.txt Nov 18 15:21:34 m5 smbd_audit: joao|192.168.1.23|arquivos|mkdir|ok|trabalho Nov 18 15:21:36 m5 smbd_audit: joao|192.168.1.23|arquivos|opendir|ok|trabalho Nov 18 15:21:43 m5 smbd_audit: joao|192.168.1.23|arquivos|open|ok|w|trabalho/Samba.sxw Nov 18 15:21:44 m5 smbd_audit: joao|192.168.1.23|arquivos|open|ok|w|trabalho/foto.jpg

O log conter entradas referentes a todos os usurios e mquinas, mas fcil ver apenas as entradas referentes a um determinado usurio, compartilhamento, endereo IP ou outro parmetro qualquer ao listar o arquivo pelo terminal usando o grep, que permite mostrar apenas as linhas contendo determinados trechos de texto, como em:

# cat /var/log/samba-full_audit.log | grep "joao|192.168.1.23"

(mostra os acessos provenientes do usurio joao, feitos a partir do endereo 192.168.1.23)

# cat /var/log/samba-full_audit.log | grep "|arquivos|"

(acessos feitos ao compartilhamento "arquivos", por parte de qualquer usurio)

... e assim por diante. Voc pode tambm direcionar a sada para um novo arquivo (ao invs de tentar l-la pelo prprio terminal), como em:

# cat /var/log/samba-full_audit.log | grep "|arquivos|" > arquivos.log

Pgina 07 de 08

Parte superior do formulrio

Parte inferior do formulrio

Backends: smbpasswd ou tdbsam


Carlos E. Morimoto24/06/2009As primeiras verses do Samba suportavam apenas o uso de senhas de texto puro, que eram transmitidas de forma no encriptada atravs da rede. Ainda possvel reverter a este sistema primitivo nas verses recentes do Samba usando a opo "encrypt passwords = no" no smb.conf, mas, alm de no trazer nenhuma vantagem, isso quebra a compatibilidade com todas as verses recentes do Windows, que no aceitam o envio de senhas em texto puro.

Durante a evoluo do Samba, foram criados diversos backends, que permitem armazenar senhas encriptadas e outras informaes referentes aos usurios. Voc pode escolher qual backend usar atravs da opo "passdb backend" do smb.conf. Vamos entender como eles funcionam.

O smbpasswd o backend mais simples. Nele, as senhas so salvas no arquivo "/etc/samba/smbpasswd" e so transmitidas de forma encriptada atravs da rede, com suporte ao sistema NTLM, usado pelas verses contemporneas do Windows. A vantagem do smbpasswd que ele um sistema bastante simples. Embora encriptadas, as senhas so armazenadas em um arquivo de texto, com uma conta por linha.

Se voc quer apenas configurar um servidor Samba para compartilhar arquivos e impressoras com a rede local, sem us-lo como PDC, ento o smbpasswd funciona bem. Ele usado por padro no Samba 3, de forma que se o arquivo smb.conf do seu servidor no contm a linha "passdb backend =" (como nos exemplos que vimos at aqui), voc est usando justamente o smbpasswd.

Em seguida temos o tdbsam, que usa uma base de dados muito mais robusta, armazenada no arquivo "/var/lib/samba/passdb.tdb" ( justamente este arquivo que o script executado durante a instalao do pacote "samba" no Debian pergunta se deve ser criado).

O tdbsam oferece duas vantagens sobre o smbpasswd: oferece um melhor desempenho em servidores com um grande nmero de usurios cadastrados e oferece suporte ao armazenamento dos controles SAM estendidos usados pelas verses server do Windows. O uso do tdbsam fortemente recomendvel caso seu servidor tenha mais do que algumas dezenas de usurios cadastrados ou caso voc pretenda usar seu servidor Samba como PDC da rede (veja mais detalhes a seguir). Ele tambm um pr-requisito caso voc precise migrar um domnio NT j existente para o servidor Samba.

Ao usar uma verso recente do Samba, ativar o uso do tbdsam bastante simples, basta incluir a linha "passdb backend = tdbsam" na seo [global] do smb.conf, como em:

[global]


workgroup = Grupo

server string = Servidor

encrypt passwords = true

wins support = yes


os level = 100

enable privileges = yes

passdb backend = tdbsamEmbora o arquivo de senhas seja diferente, o comando para cadastrar os usurios no Samba ao usar o tdbsam continua sendo o mesmo:

# smbpasswd -a usuario

Isso acontece porque, ao ser executado, o smbpasswd verifica a configurao presente no smb.conf e assim realiza as operaes necessrias para cadastrar os usurios no backend utilizado.

A principal dica que, ao utilizar o tdbsam, voc deve adicionar a linha "passdb backend = tdbsam" no smb.conf logo no incio da configurao, antes de comear a cadastrar os usurios no servidor, caso contrrio, o smbpasswd cadastrar os usurios no smbpasswd e voc precisar cadastr-los novamente para atualizar a base do tdbsam mais tarde. Em muitos casos, um script includo na distribuio pode se encarregar de fazer a converso automaticamente, mas melhor no contar com isso.

Para verificar se os usurios esto cadastrados na base de dados do tdbsam, use o comando "pdbedit -Lw" (como root). Ele deve retornar uma lista contendo todos os usurios cadastrados, como em:

# pdbedit -Lw

gdh:1006:5567A38FC604AC6B90213960766D16B5:15350B7F4983CB5EAC073A892B423E8E:[U ]:LCT-471F5AF2: root:0:E412294BCF24C19D433AC183134CC0F3:121797EEFB127E62222B23F77ED087BE:[U ]:LCT-464460FF: manuel:1005:5567A38FC604AC63902139606B6D16B5:15350B7F4983CB5EAC073A892C687E8E:[U ]:LCT-4710F13C: hp$:1007:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:0D80C51183ED74320799B5BEDDCBE388:[W ]:LCT-47421493: m5$:1009:B233C3E987D08D924405A9EF76E52792:65DD4A9908A35667D79B599F94691E34:[W ]:LCT-4742D747:

Em seguida temos o mysqlsam e o ldapsam, onde as contas e senhas so armazenadas em, respectivamente, um servidor MySQL e um servidor LDAP. O uso do MySQL em conjunto com o Samba no muito comum, mas o LDAP vem crescendo bastante em grandes redes.

A grande vantagem que o banco de dados pode ser acessado por vrios servidores, sem necessidade de replicar o arquivo de senhas manualmente (usando o rsync, por exemplo). Isso muito til no caso de redes muito grandes onde a autenticao dos usurios dividida entre vrios servidores. Nesta configurao, o PDC divide a carga de trabalho com um conjunto de BDCs (backup domain controllers), que podem ser tanto outros servidores Samba quanto servidores Windows. Os BDCs so subordinados ao servidor PDC, mas todos tem acesso mesma base de dados com os usurios, armazenada no servidor LDAP, o que evita problemas de sincronismo entre eles.

De uma forma geral, um nico PDC usando o tdbsam como backend atende bem a at 250 clientes. Este limite no relacionado ao uso do tdbsam, mas sim a questes prticas relacionadas ao desempenho da rede. Ele pode ser maior ou menor na prtica, de acordo com a velocidade da rede (100 ou 1000 megabits), o hardware do servidor e a carga sobre a rede. A partir da, passa a fazer sentido migrar para um banco de dados LDAP e passar a adicionar servidores BDC secundrios.

Confira a terceira parte em: http://www.guiadohardware.net/tutoriais/samba-pdc/Comente: http://www.guiadohardware.net/comunidade/v-t/985597/

Pgina 08 de 08

Parte superior do formulrio

Parte inferior do formulrio

_1335390028.unknown

_1335390050.unknown

_1335390027.unknown

samba parte 2

Documents