Samba
Linux in Brazil
Documentação original
e de qualidade
em bom português
e de qualidade
em bom português
|
Samba
| Linux in Brazil Documentação original e de qualidade em bom português |
Linux in Brazil tem o orgulho de apresentar mais um artigo do
Elvis Pfützenreuter, que além de ser consultor
de informática (com ênfase no uso do Linux), também já prestou muitos
serviços à comunidade brasileira, com algumas traduções e também alguns ótimos
artigos originais.
Desta vez o artigo é sobre o Samba, o pacote de software capaz de fazer o
Linux emular um servidor Windows NT. Vamos ao texto do Elvis:
versão 1.0 - 09/10/1999
Elvis Pfützenreuter - info@rootshell.com.br
O objetivo deste documento é cobrir algumas lacunas da documentação
"oficial" do Samba. v.g. SMB-HOWTO e manual on-line do arquivo
/etc/smb.conf. O diretório de documentos do Samba contém diversos
textos esparsos que lançam luz sobre os detalhes de funcionamento do
protocolo NetBIOS, e este texto procura trazer as informações mais
importantes ali contidas.
O Samba é um programa complexo e já bastante maduro. Em sua versão
estável atual - 2.0 - a única coisa que o Samba não suporta de forma
irrestrita é o conceito de domínios. Especificamente, ele não pode ser
PDC ou BDC em redes Windows NT, nem suporta o conceito de servidores
WINS redundantes. O suporte completo a domínios está previsto para a
versão 2.1, que não tardará a ser liberada.
Parece que boa parte da documentação disponível para o Samba pressupõe
conhecimento razoável sobre o protocolo NetBIOS. Infelizmente, não é
bem essa a realidade. Depois de passar alguns apuros e ficar
dependendo da sorte para que os servidores Linux aparecessem na janela
"Ambiente de Rede", criei coragem e imprimi todos os textos da
documentação esparsa do Samba (/usr/doc/samba*/docs/textdocs/*). Ali,
finalmente encontrei aquele conhecimento de baixo nível que dava
remédio a meus azares.
O protocolo NetBios foi concebido para ser simples de configurar e
usar em redes pequenas. Porém, essa aparente simplicidade desaparece
em qualquer instalação que contém duas ou mais redes Ethernet. É o que
eu chamo de "curva de aprendizado exponencial", característica que o
NetBIOS compartilha com o Windows, Visual Basic e assim por diante.
Outros procolos (TCP/IP) e softwares (Linux) obrigam seus usuários a
ter um conhecimento relativamente profundo por mais simples que seja a
tarefa; porém não reservam "surpresas" para instalações de
complexidade crescente. Portanto, desenham uma curva de aprendizado
logarítmica, de que tanto gostam os Linuxers.
Não obstante, o NetBios - assim como o DHCP, para quem o conhece - tem
o seu valor, e, uma vez dominados seus conceitos, pode ser útil e
muito adequado até mesmo em redes sem máquinas Windows.
Este documento não substitui o SMB HOWTO, nem o manual on-line do
arquivo /etc/smb.conf, nem mesmo a documentação esparsa. É um apanhado
geral que deve servir como ponto de partida, para que a leitura de
todos esses outros documentos seja mais confortável, pela prévia
dominação dos conceitos de baixo nível.
NetBIOS é um protocolo de transporte e de sessão, de uso geral, mas
primariamente destinado a serviços de arquivo e impressão. Nesse
último aspecto, é semelhante ao protocolo NCP da Novell. Porém o NCP é
um protocolo de sessão; o transporte é feito pelo protocolo subjacente
IPX (embora será muito difícil encontrar uma instalação onde IPX e NCP
não estejam "empilhados").
Para quem não sabe, protocolo de transporte é aquele que leva UM
pacote de rede da origem até o destino. Protocolo de sessão
encarrega-se de dividir seqüências arbitrariamente longas de dados em
pacotes (então transportados pelo protocolo de transporte) e
remontá-las no destino, possivelmente ordenando a retransmissão de
pacotes perdidos etc. No protocolo TCP/IP, o IP é encarregado do
transporte e o TCP, da sessão.
Como o protocolo NetBios é capaz de cuidar do transporte, não precisa
ser "carregado" por nenhum outro protocolo; pode ser constituído como
pacote de rede e transmitido. É isso que o protocolo NetBEUI da
Microsoft faz - pega os pacotes NetBIOS in natura e transmite-os rede
afora. Porém, o NetBIOS não é nativamente capaz de ser roteado;
portanto, fica "preso" à rede local.
Uma possível solução é programar os roteadores para que retransmitam
pacotes NetBIOS às outras redes; assim, o pacote NetBIOS/NetBEUI
acabará atingindo o seu destino, pois é recebido e analisado por
absolutamente todos os computadores da organização. Essa solução tem o
inconveniente de gerar um tráfego de rede infernal, e ainda mais
infernal de a comunicação inter-redes for feita através de links de
baixa velocidade.
Outra solução é encapsular o NetBIOS em um protocolo de transporte que
seja roteável, como o IPX ou o TCP/IP. De fato, a forma mais comum de
se usar serviços NetBIOS hoje é através de TCP/IP - e é a única forma
suportada pelo Samba. Como o NetBIOS não é nativamente roteável e não
aceita o conceito de endereço IP ou IPX, várias extensões foram
criadas para torná-lo mais adequado a uma instalação com diversas
redes locais. Veremo-nas todas ao longo deste texto.
Como o Samba suporta apenas NetBIOS encapsulado em TCP/IP, daqui por
diante não falaremos mais sobre outras encapsulaçòes. Apenas vale
lembrar que, ao configurar suas máquinas Windows, procure não misturar
encapsulamentos diferentes. i.e. usar NetBIOS encapsulado em IPX,
TCP/IP e NetBEUI todos ao mesmo tempo. Isso pode ser fonte de inúmeros
problemas intermitentes e dores de cabeça. Tire o NetBEUI da lista de
protocolos suportados e, se precisar usar IPX, certifique-se de que
não está habilitado o transporte de NetBIOS sobre IPX.
Como o NetBIOS se obriga a cuidar do transporte, e ao mesmo tempo não
suporta números IP, ele trabalha com técnicas de broadcasting. Uma vez
lançado um pacote na rede local, todas as máquinas receberão e
analisarão esse pacote; apenas aquela que for a máquina-destino deverá
assimilar o pacote. Obviamente existe uma identificação da máquina de
destino, que é um NOME de até 15 caracteres (doravante chamado de
"nome NetBIOS da máquina") e não um endereço númérico. Isso é muito
diferente de uma comunicação TCP/IP "normal", onde as próprias placas
de rede determinam se o pacote lhes pertence ou não, sem envolver
processamento de software.
O TCP/IP permite fazer broadcasting de uma forma muito simples:
supondo uma rede local 10.30.0.0/16, o endereço de broadcasting é
10.30.255.255. Um pacote IP emitido com esse endereço será analisado a
nível de software por todas as máquinas daquela rede local. É
exatamente esse expediente que o NetBIOS utiliza para forçar
broadcasting mesmo quando encapsulado em TCP/IP.
O uso massivo de broadcasting torna o NetBIOS muito simples de usar em
redes isoladas, pois não é necessário saber muito sobre endereços IP
para que as máquinas enxerguem umas às outras. É claro que existe o
custo (relativamente pequeno) de processamento, pois todas as máquinas
tem de analisar todos os pacotes NetBIOS a nível de software.
Como já foi dito, o broadcasting não combina muito bem com instalações
onde há várias redes locais interligadas por roteadores. Os pacotes de
broadcast não conseguem ultrapassar a fronteira do roteador. O
contorno dessa limitação está descrito no tópico 4.
Um dos aspectos mais interessantes e desconhecidos do NetBIOS está na
"eleição" do navegador-mestre local, descrito na documentação do Samba
como local master browser, e doravante aqui chamado de "mestre".
Periodicamente, os computadores de uma rede local trocam pacotes para
determinar quem tem o maior OS level. O OS level (doravante chamado de
"nível") é nada mais que um número de 0 a 255. Se não me falha a
memória, o nível do Windows 95 é 001 (decimal!), o do Windows NT é
032, e o nível padrão (porém alterável) do Samba é 033.
O computador com maior nível vencerá a eleição. Se houver mais de um
computador com o mesmo nível, haverá um desempate por critérios
aleatórios. Mesmo que a rede tenha apenas computadores Windows 95,
todos com um número de nível muito baixo, um deles acabará sendo o
escolhido.
O computador vencedor ficará responsável em compilar uma lista das
máquinas presentes na rede local. Não surpreendentemente, ele usará
técnicas de broadcasting para esse fim. Os demais computadores obterão
essa lista junto ao mestre. É justamente essa lista que aparece na
janela "Ambiente de Rede" do Windows.
É importante entender que, numa rede local, há apenas um computador
tomando conta da lista. Pode até parecer, pela demora no surgimento da
janela, que cada computador desbrava a rede por conta própria, mas NÃO
é isso que acontece.
Agora a primeira "pedra" onde alguém pode tropeçar. O Windows NT não
gosta de perder a eleição para o Samba se ambos tiverem o mesmo OS
level. Portanto, nunca configure o Samba com o mesmo OS level que o
Windows NT. Configurar o Samba para que ele nunca vença a eleição para
mestre, ou então use o maior nível possível (255).
Note que todo esse processo ocorre dentro de uma rede local. O fato de
um computador ser o mestre de uma rede (ainda) não lhe dá o poder de
enxergar as demais redes da instalação. Isso é assunto para o tópico
4.
Um detalhe importantíssimo: mesmo dentro de uma única rede local,
haverá um mestre para cada grupo de trabalho (workgroup). Portanto, se
você quer que todas as máquinas se enxerguem, tome o cuidado de
configurá-las todas com o mesmo grupo de trabalho. Ou, se deseja
isolar grupos de máquinas dentro de uma rede isolada, configure
deliberadamente com grupos diferentes.
O sintoma mais aparente de um computador com grupo de trabalho
configurado incorretamente é o fato de ele não enxergar nenhum
computador na janela Ambiente de Rede; quando muito, enxerga apenas o
grupo de trabalho. Exemplo: o grupo de trabalho é VITARA e um
computador está configurado para o grupo VITARE. Esse último
computador está num grupo isolado e tornar-se-á o mestre daquele
grupo. Obviamente, a lista que ele mesmo compilou só contém um
computador, pois as demais máquinas da rede estão em outro grupo de
trabalho e elegeram outro mestre.
Se o computador-mestre for desligado, alguma outra máquina procurará
pelo mestre, e não o achará. Nesse caso, uma nova eleição é efetuada.
Esse é um ponto interessante do NetBIOS: redundância automática.
Forçando um pouco os conceitos, pode-se dizer que um domínio é um
grupo de trabalho onde haja pelo menos um computador "responsável" por
ele - é o mestre do domínio. (Temos aqui um conceito recursivo, eu
acho.)
No mundo Windows NT, o mestre do domínio é o próprio PDC - primary
domain controller. Já o Samba, que ainda não suporta completamente
todas as funções de um controlador de domínio NT (*), pode ser
explicitamente configurado para ser apenas o navegador-mestre do
domínio.
(*) A versão 2.1 do Samba deve trazer suporte quase completo a
controle de domínio e BDCs.
O mestre do domínio compilará a lista de TODAS as máquinas do grupo de
trabalho, mesmo que estejam em outras redes locais. Além disso, por
ser uma máquina privilegiada, vencerá sempre as eleições para mestre
da rede local, pois não faria sentido haver um mestre local e um
mestre de domínio separados.
Deve haver APENAS UM mestre de domínio por domínio. Tenha em mente que
o NT costuma ser configurado em tempo de instalação para ser o mestre
do domínio. Tome cuidado com isso ao instalar outras máquinas NT, e
principalmente, não configure o Samba para ser mestre de domínio sem
antes verificar as configurações dos servidores NT. Como não existe
eleição para mestre de domínio, a presença de mais de um mestre é
fonte certa de problemas, principalmente se um dos pretensos mestres
de domínio for NT.
Agora, resta saber como o mestre do domínio consegue descobrir os
nomes das máquinas de fora da rede local. As bases estão nos tópicos 4
e 5, e o mecanismo prático está descrito no tópico 6.
Como o NetBIOS utiliza-se de broadcasting, fica restrito à rede local,
pelo menos nas instalações "sérias". Para que o NetBIOS possa
ultrapassar as fronteiras da rede local, três mecanismos são
necessários:
- capacidade de comunicar-se diretamente com outros computadores pelo
número IP, pois só assim os roteadores aceitarão transportar os
pacotes;
- capacidade de traduzir nomes NetBIOS para números IP, para que o
usuário não perca a comodidade de usar nomes NetBIOS;
- capacidade de compilar listas que contenham todos os computadores de
todas as redes da instalação.
A implementação da Microsoft para o protocolo NetBIOS foi estendida de
modo a cumprir o primeiro quesito, e uma extensão "externa" ao
NetBIOS, denominada WINS, cumpre os demais quesitos.
Assim, modernamente o NetBIOS não depende mais exclusivamente do
broadcasting para fazer o transporte. Se houver um mecanismo qualquer
que identifique o número IP da máquina de destino, o pacote NetBIOS
encapsulado em TCP/IP será mandado diretamente ao IP do
computador-destino, mesmo que esse IP esteja fora da rede local, pois
os roteadores serão capazes de transportá-lo. É possível inclusive
trafegar NetBIOS pela Internet pública !
O mecanismo mais primitivo de tradução de nomes NetBIOS para endereços
IP é o arquivo c:\windows\lmhosts ou /etc/lmhosts. É uma lista pura e
simples dos nomes NetBIOS com os endereços IP ao lado. Logo
descobre-se as desvantagens desse mecanismo: cada computador tem de
ter a sua lista, as atualizações também precisam ser feitas em todas
as máquinas, e os computadores desse arquivo não aparecem na janela
Ambiente de Rede. O ideal seria que a tradução funcionasse de modo
análogo ao DNS.
Entra o serviço WINS, que opera de modo análogo ao DNS. Note que eu
disse análogo, e não semelhante, nem paralelo, nem igual. O WINS é
contactado diretamente pelo número IP - nada de broadcasting para
localizar o servidor WINS, até porque ele não faz parte do NetBIOS em
si.
O WINS não tem um cadastro estático de computadores. Ele recebe
informações de todos os computadores da instalação e, dinamicamente,
vai formando uma lista de todos os computadores da rede: nomes
NetBIOS, grupos de trabalho e os respectivos endereços IP. O servidor
WINS mantém cadastros de todas as máquinas da instalação,
independentemente do grupo de trabalho. Por isso mesmo, deve haver
apenas um servidor WINS na instalação inteira, mesmo que haja vários
grupos de trabalho e/ou mestres de domínio.
NÃO confunda o servidor WINS com o mestre do domínio. Embora é comum
rodar o WINS na própria máquina que foi designada como mestre do
domínio, é perfeitamente possível que os dois residam em computadores
separados!
Também lembre-se que não existe nenhuma integração automática entre
DNS e WINS, mesmo que ambos rodem no mesmo servidor. O fato de
cadastrar o nome DNS de um computador não significa que o servidor
WINS vá passar a conhecer o endereço IP do mesmo.
Existem alguns mecanismos de fallback onde o nome NetBIOS é consultado
junto ao servidor DNS se o servidor WINS não responder à consulta, mas
a própria documentação do Samba desaconselha seu uso. Em grandes
instalações com muitas estações de trabalho, é muito comum (e
aconselhável) o uso de DHCP, o que torna o DNS completamente inútil
para acesso inter-estações.
O documento BROWSING-Config.txt contém uma excelente descrição de como
o mestre de domínio consegue compilar a lista de todos os computadores
de uma instalação. Considere a descrição a seguir uma cópia pálida e
"mastigada".
Suponha que haja três redes locais interligadas por roteadores: A, B e
C. Suponha também que em cada rede haja cinco computadores, e que
todos, independentemente do sistema operacional, ofereçam serviços
NetBIOS. Suponha também que:
- O nome do grupo de trabalho/domínio seja ACME;
- O computador A_2 seja o mestre de domínio;
- O computador A_3 seja o servidor WINS e seu IP é 10.30.14.56;
- Todos os computadores estejam configurados corretamente e "saibam"
que o endereço IP do servidor WINS é 10.30.14.56;
- Os computadores A_1, B_1 e C_1 estejam rodando o Samba e, exceto por
A_1, estejam programados para vencer as eleições para mestre local.
Tão logo os computadores sejam ligados, haverá eleições para mestre em
cada uma das redes locais. Nas redes B e C, os computadores B_1 e C_1
vencerão. Na rede A, o computador A_2 vencerá a eleição pois é o
mestre do domínio e isso lhe dá preponderância sobre todas as outras
máquinas da rede.
O mestre do domínio (A_2) registrará o domínio junto ao servidor WINS
(A_3). Da mesma forma, todas as outras máquinas registrarão seus nomes
NetBIOS, grupos de trabalho e números IP junto ao servidor WINS.
Os computadores começarão a anunciar a si mesmos por pacotes de
broadcast. Atentos, os mestres locais compilarão uma lista das
máquinas de cada rede. Nesse instante, os mestres de cada rede local
conterão as seguintes listas de computadores:
A_2: -> A_1, A_2, A_3, A_4, A_5
B_1: -> B_1, B_2, B_3, B_4, B_5
C_1: -> C_1, C_2, C_3, C_4, C_5
Até agora, nenhuma rede tem conhecimento da existência das demais
redes.
Cada um dos computadores de todas as redes vai contactar o servidor
WINS (A_3) e registrar-se junto a ele. Nesse ponto, o servidor WINS
conhece os nomes NetBios, grupos de trabalho e endereços IP de todas
as máquinas. Como o WINS funciona independente do mestre de domínio
A_2, este último continua com sua lista incompleta.
Cada mestre local (B_1 e C_1) contacta o servidor WINS e descobre o
endereço IP do mestre de domínio (A_2.). A seguir, o mestre local
contacta o mestre do domínio e transmite a ele a lista de todas as
máquinas do grupo de trabalho. Em troca, o mestre de domínio transmite
ao mestre local a lista geral dos computadores do domínio.
Supondo que os mestres locais B_1 e C_1 contactem o mestre de domínio A_2 em ordem, as listas em cada servidor ficarão assim:
A_2: -> A_1, A_2, A_3, A_4, A_5, B_1, B_2, B_3, B_4, B_5, C_1, C_2,
C_3, C_4, C_5
B_1: -> B_1, B_2, B_3, B_4, B_5, A_1, A_2, A_3, A_4, A_5
C_1: -> C_1, C_2, C_3, C_4, C_5, A_1, A_2, A_3, A_4, A_5, B_1, B_2,
B_3, B_4, B_5
O servidor B_1 contactou A_2 antes de C_1. Naquele instante, A_2 ainda
não sabia que a rede C existia. Por isso, a lista do servidor B_1
ficou prejudicada. Já o servidor C_1 contactou o mestre de domínio A_2
quando este último já tinha recebido a lista da rede B. (Está claro
que a lista da rede "A" tinha sido compilada pelo próprio mestre do
domínio A_2.)
Dentro de 15 minutos, os mestres locais contactarão novamente o mestre
de domínio para retransmitir e atualizar as listas. Nesse momento, o
mestre de domínio A_2 já conhece a rede inteira, e o mestre local B_1
poderá completar sua lista:
A_2: -> A_1, A_2, A_3, A_4, A_5, B_1, B_2, B_3, B_4, B_5, C_1, C_2,
C_3, C_4, C_5
B_1: -> B_1, B_2, B_3, B_4, B_5, A_1, A_2, A_3, A_4, A_5, C_1, C_2,
C_3, C_4, C_5
C_1: -> C_1, C_2, C_3, C_4, C_5, A_1, A_2, A_3, A_4, A_5, B_1, B_2,
B_3, B_4, B_5
Agora, todos os computadores da rede aparecerão na janela "Ambiente de
Rede" de qualquer das estações.
Lembre-se sempre disto: a lista de máquinas NÃO vai aparecer completa
imediatamente. Pode levar até 30 minutos até que todos os mestres
locais tenham a lista completa da rede. Da mesma forma, se um dos
computadores for desligado ou uma rede for desconectada, haverá um
lapso de tempo durante o qual a máquina continuará aparecendo nas
listas (36 minutos), até que o mestre local da rede desligada
finalmente retire-a da lista e informe o fato ao mestre do domínio.
Supondo agora que o computador C_4 quer comunicar-se com o computador
A_5. Pela lista, ele sabe que o computador A_5 existe, mas não sabe
qual é seu endereço IP. Então, C_4 consulta o servidor WINS, obtém o
endereço IP e contacta A_5 diretamente, sem usar broadcast. Note bem
aqui como o trabalho de compilação de listas é independente do
servidor WINS.
O Samba suporta quatro formas de autenticação de usuários, reguladas
pela linha security = ... do arquivo /etc/smb.conf. Assuma, até
segunda ordem, que estamos falando de senhas não criptografadas.
SHARE: Sem segurança. Todo e qualquer usuário será aceito. As
operações de arquivo e impressão serão executadas com as permissões do
usuário UNIX associado ao hóspede (guest account = ...). Se você
escolher essa modalidade, verifique se o usuário UNIX terá permissões
suficientes para acessar arquivos e, se for o caso, imprimir.
USER: Segurança por usuário, local. A senha do usuário é reduzida a
letras minúsculas e confrontada com a senha UNIX. Essa modalidade de
segurança obriga que os usuários sejam cadastrados no Linux, e suas
senhas sejam atribuídas corretamente. As operações sobre arquivos e de
impressão serão feitas com a permissão do respectivo usuário UNIX.
Todavia, pode-se abrir aos hóspedes o acesso a determinados volumes ou
impressoras - para esses objetos, a segurança operará no estilo SHARE.
SERVER: Segurança por usuário, remota. O Samba pega o nome de usuário
e a senha, e autentica junto a outro servidor, que poderá ser outro
Linux rodando Samba, ou um Windows NT. Apesar da autenticação ser
remota, ainda é necessário criar os usuários UNIX localmente em
determinados casos. (Consulte a linha map to guest = Bad User do
arquivo de configuração comentado.)
DOMAIN: Segurança por usuário, remota. Praticamente idêntica à
modalidade SERVER, porém convive com instalações mais complexas onde
existem computadores NT operando como PDCs (primary domain
controllers) e BDCs (backup domain controllers). Nesse modo, mais de
um servidor de autenticação pode ser especificado na linha password
server do arquivo de configuração. É necessário criar uma conta no
servidor de domínio para que o Samba identifique a si mesmo junto ao
NT. (O suporte do Samba a domínios do NT ainda é incompleto e deve
estar pronto na versão 2.1; por ora, a modalidade DOMAIN não difere
muito da modalidade SERVER.)
O Windows 98, bem como versões mais recentes do Windows NT
Workstation, transmitem senhas criptografadas no processo de
autenticação. Isso torna a configuração do Samba bem mais complicada,
especialmente na modalidade USER, pois ele tem de armazenar as senhas
num arquivo separado (/etc/smbpasswd), mantida por um utilitário não
padrão do Unix (smbpasswd). O esquema de encriptação do NetBIOS é
completamente diferente do Unix, portanto não há possibilidade de usar
as senhas armazenadas em /etc/passwd.
A verdade é que as senhas criptografadas não adicionam quase nenhuma
segurança ao NetBIOS, por razões diversas. (Portanto, NÃO pense que
trafegar NetBIOS na Internet pública é seguro, mesmo usando senhas
criptografadas !!!) Sendo assim, por amor à comodidade, o melhor a
fazer é configurar o Windows 98/NT para usar senhas não
criptografadas.
Para fazer isso, você deve adicionar um item no Registro do Windows.
Consulte o diretório /usr/samba*/docs. Lá você encontrará uns arquivos
*.reg que, em conjunção ao REGEDIT do Windows, criam esses itens
automaticamente nos diversos "sabores" de Windows.
Você pode consultar aqui um arquivo-exemplo
de configuração,
totalmente comentado e coerente com as explicações dos demais tópicos.
[em construção]
Segue algumas opções avançadas do arquivo smb.conf. Sua descrição
completa tornaria esse documento muito longo (bem, agora é tarde, ele
JÁ ESTÁ longo demais!), mas elas mereciam pelo menos ser citadas.
Você pode consultar o manual on-line do arquivo smb.conf (com man
smb.conf) para obter a explanação completa acerca destas e de todas as
outras opções de configuração do Samba.
add user script
- permite adicionar usuários automaticamente ao Linux, via script.
Isso contradiz a informação de que "usuários NetBIOS tem de ser
cadastrados manualmente no Linux para que tenham acesso aos
recursos...". Pode ser MUITO interessante em instalações com
grande número de usuários.
admin users
- usuários administrativos, que terão acesso equivalente a root
aos arquivos dos volumes. Pode ser útil para criar usuários
de backup, sem ter de se preocupar com permissões de leitura
etc. Esse parâmetro pode ser específico por volume i.e.
especificado na descrição do volume e com validade restrita
a ele.
auto services
- Lista de serviços que serão automaticamentes adicionados às
listas de navegação. Úteis para diretórios-base de usuários
e impressoras, que de outra forma não seriam visíveis.
bind interfaces only
- Fará com que o Samba atenda somente as requisições que tenham
vindo através das interfaces especificadas no parâmetro
'interfaces'. Dependendo de sua necessidade, pode ser uma
forma de segurança mais limpa que o 'hosts allow'.
guest only
- Permite que apenas o hóspede tenha acesso ao volume ou
impressora que contiver o parâmetro 'guest only = yes'
Até aqui, foi dado a entender que a única forma de configurar o Samba
é editar manualmente o arquivo /etc/smb.conf. Isso pode ser suficiente
(ou mesmo preferível) para muitos administradores de sistemas. Porém
muitos prefeririam um meio mais "soft" de configurar o Samba, tal como
uma interface GUI, ou mesmo uma interface de texto orientada a menus.
Há várias formas alternativas de configurar o Samba sem "sujar as
mãos" no /etc/smb.conf:
- existe um módulo LinuxConf para esse fim. Por sua vez, o LinuxComf
oferece concomitantemente as interfaces texto, gráfica e
Web, portanto já são três opções de configuração amigável;
- ksamba, um programa GUI voltado ao ambiente gráfico KDE;
- programas interpretados em Tcl/Tk;
- programas que atuam como CGIs (interface Web).