A seção [global]

Todas as opções colocadas dentro da seção referente ao compartilhamento valem apenas para ele, o que permite que você crie diversos compartilhamentos diferentes e use um conjunto próprio de permissões para cada um. Estas mesmas opções, junto com um conjunto adicional podem ser especificadas de forma geral dentro da seção [global] do smb.conf.

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

Em primeiro lugar, temos o nível de segurança do servidor, definido através da opção “security”. O default no Samba 3 é usar o controle de acesso baseado em usuário, que é o mesmo modo de acesso usado pelas versões domésticas do Windows 2000, XP e Vista. Neste modo, você cadastra os logins e senhas no servidor, define as permissões de acesso e o servidor checa as credenciais dos clientes antes de autorizar o acesso, a configuração que vimos até aqui. Este modo é ativado adicionando a opção “security = user” na seção [global], mas não é necessário usá-la no Samba 3, pois, como disse, ela é usada por padrão:

security = user

Em seguida, temos o modo “security = domain”. Ao contrário do que o nome pode sugerir à primeira vista, este modo não é destinado a fazer com que o Samba atue como um controlador de domínio. Pelo contrário, ao configurar um servidor Samba como PDC, você continua usando a opção “security = user”, da mesma forma que faria ao usar um servidor em modo stand alone. A opção “security = domain” é usada quando você quer que um servidor Samba participe do domínio 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 estações Windows 95/98. Estes dois modos são obsoletos e devem ser removidos em futuras versões do Samba. Antigamente, o modo “security = share” era usado em casos onde você queria disponibilizar compartilhamentos públicos na rede, sem muita segurança, 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 não era capaz de atuar como PDC; este modo permitia que ele atuasse como um proxy de autenticação, repassando as requisições para o servidor de autenticação principal. Atualmente este modo não é mais usado.

Outra opção usada por padrão no Samba 3 é a “encrypt passwords = yes“, de forma que também não é necessário especificá-la manualmente no arquivo. Entretanto, é saudável incluí-la em modelos e exemplos de configuração pois pode acontecer de alguém tentar usar o modelo no Samba 2, onde o default era que ela ficasse desativada.

encrypt passwords = yes

É muito comum que seja incluída também a opção “invalid users = root“, uma medida de segurança para evitar que a conta de root seja usada ao acessar o servidor. A lógica é que a conta de root é a única conta presente em qualquer sistema Linux, de forma que alguém que decidisse usar um ataque de força bruta para tentar obter acesso ao servidor, testando todas as senhas possíveis, começaria justamente pela conta de root.

Entretanto, a conta de root é necessária para dar upload de drivers de impressão e para logar os clientes ao usar o servidor Samba como PDC, situações onde a linha “invalid users = root” deve ser comentada ou removida.

Continuando, as opções definidas dentro da seção [global] valem para todos os compartilhamentos do servidor, diferente das opções colocadas dentro da seção referente a cada um. Por exemplo, ao usar:

[global]
netbios name = Servidor
workgroup = Grupo
hosts allow = 192.168.1.

… apenas as máquinas dentro da faixa de endereços especificadas terão acesso ao servidor, o que seria interessante do ponto de vista da segurança, já que de qualquer forma o servidor deve ser acessado apenas por clientes da rede local.

O maior problema é que a opção “hosts allow” usada na seção [global] tem precedência sobre qualquer opção “hosts deny” usada dentro dos compartilhamentos, o que pode criar problemas caso você queira restringir o acesso de alguma máquina da rede local a um determinado compartilhamento.

Por exemplo, ao usar:

[global]
netbios name = Servidor
workgroup = Grupo
hosts allow = 192.168.1.

[share]
path = /mnt/sda2/shared
hosts deny = 192.168.1.2

… a máquina “192.168.1.2” continuaria tendo acesso ao compartilhamento [share], pois o acesso é autorizado pela opção “hosts allow = 192.168.1.” usada na seção [global]. Nesse caso, o melhor seria remover a linha “hosts allow = 192.168.1.” da seção [global] e deixar apenas a opção “hosts deny = 192.168.1.2” na seção [share]:

[global]
netbios name = Servidor
workgroup = Grupo

[share]
path = /mnt/sda2/shared
hosts deny = 192.168.1.2

Em caso de conflito direto entre uma regra definida na seção [global] e outra definida em um dos compartilhamentos, a regra definida na seção [global] tem precedência. Por exemplo, ao usar:

[global]
netbios name = Servidor
workgroup = Grupo
hosts deny = 192.168.1.3

[share]
path = /mnt/sda2/shared
hosts allow = 192.168.1.3

… a máquina “192.168.1.3” continuará sem acesso ao compartilhamento “share” (ou a qualquer outro recurso do servidor), já que vale a regra definida na seção [global]. Enquanto a linha “hosts deny = 192.168.1.3” não for removida, a máquina não terá acesso a nenhum dos compartilhamentos, não importa o que digam as demais linhas do arquivo.

Continuando, um problema comum enfrentado ao administrar uma rede mista são os usuários escreverem a primeira letra do login em maiúsculo, como em “Joao” no lugar de “joao”. No Windows isso não é 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 opção “username level”, como em:

username level = 2

Esta opção faz com que o Samba verifique várias combinações de maiúsculas e minúsculas caso o login seja recusado pelo sistema. O número indica o volume de variações, que pode ser qualquer número inteiro. Ao usar o valor “2”, o Samba verifica até dois níveis, incluindo variações como JOao, jOAo, Joao, jOaO e assim por diante. Usar um número maior pode retardar a autenticação, já que o Samba precisará testar muitas combinações, por isso são geralmente usados os valores “1” ou “2”.

Outra peculiaridade digna de nota é a questão dos nomes de arquivos. No Windows, os nomes de arquivos são salvos da forma como digitados pelo usuário, preservando os caracteres maiúsculos e minúsculos. Entretanto, o sistema é case insensitive, de forma que o sistema não 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 máquina 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 combinações de maiúsculas e minúsculas.

No Samba 3 este recurso funciona muito bem, mas tem a desvantagem de consumir uma certa quantidade de memória do servidor. Em um pequeno servidor de rede local, isso não faz diferença, mas em um servidor que atende um grande número de requisições, a diferença pode se tornar considerável.

Você pode simplificar as coisas orientando o Samba a salvar todos os arquivos em minúsculas. 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 através da opção “interfaces“, que deve ser combinada com a opção “bind interfaces only = yes”. Para que o servidor escute apenas a interface eth0, ignorando tentativas de conexão em outras interfaces, você usaria:

interfaces = eth0
bind interfaces only = yes

Por default, o Samba escuta em todas as interfaces, o que (se não houver nenhum firewall ativo) pode expor seus compartilhamentos para a Internet caso você ative o Samba em uma máquina conectada diretamente à internet, como no caso de um servidor que compartilha a conexão. É recomendável usar sempre estas duas opções, como uma forma de garantir que o Samba ficará disponível apenas na interface desejada.

Outra opção 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 várias máquinas. Geralmente, isso acaba confundindo mais do que ajudando, mas pode ser útil em algumas situações, quando, por exemplo, um servidor é desativado e os compartilhamentos são movidos para outro. O novo servidor pode responder pelo nome do servidor antigo, permitindo que os desavisados continuem acessando os compartilhamentos através do endereço anterior. Para usá-la, basta adicionar a opção, seguida pelos apelidos desejados, como em:

[global]
netbios name = Servidor
netbios aliases = athenas, sparta
workgroup = Grupo

No tópico sobre o Swat falei sobre as opções “Local Master”, “OS Level” e “Preferred Master”, que definem se o servidor Samba deve participar das eleições para Master Browser e com qual nível 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 opção OS Level, como em:

local master = yes
os level = 90
preferred master = no

O valor da opção OS Level é absoluto, não 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 três linhas, o servidor simplesmente utiliza os valores default (local master = yes, os level = 20), que fazem com que ele participe das eleições, mas utilize credenciais baixas.

A opção “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, responsável pela navegação na rede e listagem dos compartilhamentos e outros recursos disponíveis, de forma similar a um servidor DNS.

O uso do WINS não é obrigatório; 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 navegação (a menos que você utilize um domínio), o que aumenta o tráfego da rede e torna todo o processo mais passível de falhas.

Outra limitação importante é que os pacotes de broadcast são descartados pelos roteadores, o que faz com que eles (os pacotes de broadcast) não sejam transmitidos de um segmento a outro da rede caso ela esteja dividida em vários segmentos, interligados através de roteadores. O mesmo acontece caso você tenha duas redes ligadas através de uma VPN, onde o tráfego seja roteado. Em ambos os casos, os pacotes de broadcast são descartados pelos roteadores, fazendo com que os micros em um segmento não enxerguem os micros do outro e vice-versa.

A solução em ambos os casos é implantar um servidor WINS na rede. Com isso, os clientes passam a consultar o servidor ao invés de mandar pacotes de broadcast, fazendo com que a navegação funcione mesmo ao utilizar vários segmentos de rede. Para isso, basta incluir a opção dentro da seção [global] do smb.conf:

wins support = yes

O próximo passo é configurar os clientes da rede para utilizarem o servidor. A opção fica escondida nas propriedades da conexão de rede, no Protocolo TCP/IP > Propriedades > Avançado > WINS, onde você deve adicionar o endereço IP do servidor:

m1b9007bf

A configuração do servidor WINS pode ser também enviada automaticamente para os clientes. Para isso, é necessário incluir a opção “netbios-name-servers” na configuração 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 seção com a configuração 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 configuração é feita adicionando a opção “wins server = servidor” (também na seção [global] do smb.conf), onde você especifica o endereço IP do servidor principal, como em:

wins server = 192.168.1.254

Uma observação importante é que as opções “wins support” e “wins server” são mutuamente exclusivas. Ou a máquina atua como servidor WINS, ou como cliente (nunca as duas coisas ao mesmo tempo), de forma que você não deve jamais combinar as duas opções dentro da configuração.

Em versões antigas do Samba, combinar as duas opções na configuração simplesmente fazia com que o servidor deixasse de funcionar. Nas atuais o resultado não chega a ser dramático (o servidor vai simplesmente ignorar a opção que for colocada depois), mas mesmo assim este é um erro grave de configuração que deve ser evitado.

Um exemplo de seção [global] usando as opções 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
preferred master = yes
wins support = yes

Esta configuração ativa o teste de variações de maiúsculas e minúsculas para os logins recusados (apenas um nível), faz com que todos os arquivos salvos nos compartilhamentos sejam renomeados para caracteres minúsculos, 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 configuração perfeitamente utilizável, faltaria apenas adicionar as seções referentes aos compartilhamentos.

Sobre o Autor

Redes Sociais:

Deixe seu comentário

X